dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

I just tried - you can't override those settings with an external
file.  They will always kick in after the configuration is loaded.
Which is very inflexible.  For example even the logging level is
fixed.

I think its worth reconsidering.

On 9 June 2015 at 09:00, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> Hi Lars
>
> On 9 June 2015 at 07:37, Lars Helge Øverland <larshelge@xxxxxxxxx> wrote:
>> Hi Bob,
>>
>> thanks for the feedback.
>>
>> Yes the main reason for having a java based default config is to be able to
>> set the log file path to the dhis home directory. Yes the env var support in
>> log4j 2 is cool but it is not sufficient in our use case since dhis config
>> loading is more complex - it looks for 1) a system property dhis2.home, 2)
>> an env variable DHIS2_HOME and 3) eventually falls back to using
>> <user-home-dir>/opt/dhis2. I know DHIS 2 Live uses 2) and I know many
>> deployments which use 3). So there is no guarantee that DHIS2_HOME is set,
>> hence it is not a reliable solution.
>
> I suspect both these use cases are not as valid as they once were.
> dhis2-live provides its own log4j.properties file anyway so wouldn't
> be an issue.  And (3) which uses /opt/dhis2 is a hangover from a bad
> idea of mine for packaging a deb.  I am not sure i would recommend it
> at all  - but would rather just simplify the code in dhis2 back to the
> env variable.   Anyway, see below ...
>
>> Re XML vs config files - config files are more flexible in general but in
>> this scenario it makes no difference. In any case you don't want to modify
>> or remove config files which are bundled inside the WAR file since those
>> changes will be wiped next time the WAR is upgraded, but rather append /
>> override it with an external file. You can have your external file override
>> the default DHIS 2 config, irrespective of that default config being set in
>> Java or from a config file.
>
> That is the important point.  I assumed that if you were configuring
> in java that you would not be able to override those settings with an
> external config file (I wasn't planning to fiddle with the internal
> one).  Has anyone tried this?  If it is indeed the case that it can be
> overridden then of course it makes no difference at all what the java
> code does or doesn't do which is fine.  Except of course having all
> this in code does make moving (eg to log4j 2) a bit more difficult.