dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

I just had a quick check of log4j 2.  Upgrading seems as
straightforward as replacing the 1.2.7 dependency with:

      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>2.3</version>
      </dependency>
      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.3</version>
      </dependency>
      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-1.2-api</artifactId>
        <version>2.3</version>
      </dependency>

Note the last dependency just provides an adaptor so the old log4j
code will still work (except for programmatic configuration).
Providing a config file for the new settings does seem much better
than hard coding them.  One very useful feature I see in log4j 2
(besides the ability to use env variables and system properties in the
config file) is the ability to reload the log4j configuration without
restarting the server.  See "Configuration Syntax" monitorInterval at
http://logging.apache.org/log4j/2.x/manual/configuration.html.
That's something I've often wished for.

Can I ask again .. is the main reason for doing this programatically
so that we can direct logging to DHIS2_HOME?  If so, then let's do it
this way instead.

On 8 June 2015 at 13:42, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> Maybe a better approach would be to upgrade log4j 1.2.7 to log4j 2 -
> which allows for example to refer to envronment variables (like
> DHIS2_HOME) in the configuration.
>
> On 8 June 2015 at 13:37, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>> Ah!! I have just noticed that this new logging regime is actually
>> hardcoded in java.  That strikes me as a really bad idea.  Can we not
>> achieve exactly the same effect as you get in code by providing a
>> default log4j.xml file bundled in the war which could be overriden by
>> an external file.
>>
>> Whereas having a sensible out-of-the-box logging setup makes sense, I
>> can't really see any benefit at all in doing this with code rather
>> than configuration.  What I would rather do, for example, is to have a
>> log4j config file bundled with dhis2-tools which is maybe a copy of
>> the default config.  Then implementers could tweak if they saw fit.
>> Similar with devs or docker folk who might want to fall back to
>> catalina.out.
>>
>> What is the reason for configuring the logging with compiled code?  Is
>> it just to to specify the default logging location based on
>> DHIS2_HOME?
>>
>> On 8 June 2015 at 13:06, Halvdan Grelland <halvdanhg@xxxxxxxxx> wrote:
>>> If the log4j config is overridable at launch we could always add a property
>>> pointing to a development config in the maven dev profile. I'm not sure how
>>> that would play with this though as it's being configured programmatically
>>> at application startup.
>>>
>>> Thoughts Lars?
>>>
>>> 2015-06-08 3:45 GMT+02:00 Morten Olav Hansen <mortenoh@xxxxxxxxx>:
>>>>
>>>>
>>>> On Sun, Jun 7, 2015 at 10:37 PM, Lars Helge Øverland <larshelge@xxxxxxxxx>
>>>> wrote:
>>>>>
>>>>> No everything generated by DHIS 2 including exceptions go into the main
>>>>> dhis.log file. We should of course aim at fixing the cause of these errors.
>>>>
>>>>
>>>> Is there an easy way to switch this off during development? Having to tail
>>>> an extra log file every time doesn't sounds very convenient..
>>>>
>>>> --
>>>> Morten
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>