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
