James3 Reading configuration via classpath [unsigned]

[Bernd Waibel <BW...@intarsys.de>]

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

Re: James3 Reading configuration via classpath [unsigned]

[Ioan Eugen Stan <st...@gmail.com>]

Hi,

I have not worked on James recently so I might be too generic in
expression and not very helpfull. Appologies if that is the case.


On 25.07.2016 15:07, Bernd Waibel wrote:
> 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?

I believe it should not be this way as it limits how you can change
configuration in production deployments. It should be loaded from a
system property.

> 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?

I agree this should be changed. The code should be in the main class.

> 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 agree. We use this case when we have deployments. We always start the
application based on a symlink called 'current' or similar.

We unpack a new version of the application and point current symlink to
it. That way we can rollback easy. The configuratio directory is outside
of current and we don't need to change anything.


> 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
> 
> 

I agree with you. James should be configured via system properties. It
should try a default path if no value is given.

It would be great if you submit a patch or a pull request. I can help
you with more information on how to do this.

Regards,

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org