dhis2-users team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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.