james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Waibel <BWai...@intarsys.de>
Subject James3 Reading configuration via classpath [unsigned]
Date Mon, 25 Jul 2016 12:07:58 GMT
Hello together,

it seems to me, that James3 is reading his configuration files (/conf/*.xml) via "classpath:".
Is this a design decision? Why does it work like this?

The "conf" directory has to be on classpath, or James does not start. And it must be the "first"
of all classpath entries.
Is there any kind of configuration, to change this behavior?

My aim is, to make the configuration available to a user who acts as a "james configuration
manager".
He should configure the application, but not be able to change the code of the application.
Furthermore, there should be one installation, which could be run with different configurations
(e.g. a multi-homed server).

I do not like configuration files on classpath:

1.       If we use the classpath to load the configuration, we are able to put any JAR file
into the configuration directory.
This JAR file will be loaded first, so e.g. it could be a "james-server-app-3.0.0-beta5-SNAPSHOT.jar".
This will lead to the fact, that I could hack the implementation by placing a hacked james-jar
inside the configuration directory.
Is this an aim of the current implementation?

2.       If you do not place a configuration file inside the conf directory, any configuration
file found in any jar will be used.

E.g. the imapserver.xml is deployed inside the james-server-protocol-imap4.jar, and is available
on classpath, outside conf directory.
If we do not deploy a imapserver.xml inside the conf directory, the "default" implemented
will be used.
Is this an aim of the current implementation?

I normally want to split "configuration" from "implementation", but only for "business configuration".
I do understand, that the configuration of the "beans" need to stay inside the implementation.


The reason for the current implementation seems to be coded in class ConfigurationProviderImpl,
as it has the following implementation:
    /**
     * Return the configuration prefix to load the configuration. In this case
     * it is classpath:, but could be also file://conf/
     *
     * @return prefix
     */
    private String getConfigPrefix() {
        return "classpath:";
    }

Shouldn't it be better to use file://conf here instead?
Does someone know any side effects if we do this?
Should I create a ticket/patch?

Greetings
Bernd


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message