On Tue, Jun 9, 2015 at 11:19 AM, Bob Jolliffe bobjolli...@gmail.com wrote:
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
Yes that is what I just tested. It loads the log4 configuration file.
But this doesn't prevent the java code from running so it configures
twice.
On 9 June 2015 at 10:38, Lars Helge Øverland larshe...@gmail.com wrote:
On Tue, Jun 9, 2015 at 11:19 AM, Bob Jolliffe bobjolli...@gmail.com wrote:
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
Hi Lars
On 9 June 2015 at 07:37, Lars Helge Øverland larshe...@gmail.com 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
Okay that's weird. If so I can look for log4j.configuration i the java
config loader and exit if that system prop is present?
On Tue, Jun 9, 2015 at 11:48 AM, Bob Jolliffe bobjolli...@gmail.com wrote:
Yes that is what I just tested. It loads the log4 configuration file.
But this doesn't
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
On Tue, Jun 9, 2015 at 11:48 AM, Bob Jolliffe bobjolli...@gmail.com wrote:
Yes that is what I just tested. It loads the log4 configuration file.
But this doesn't prevent the java code from running so it configures
twice.
For the record I did a small fix to abort the default log config when
I just had a quick check of log4j 2. Upgrading seems as
straightforward as replacing the 1.2.7 dependency with:
dependency
groupIdorg.apache.logging.log4j/groupId
artifactIdlog4j-api/artifactId
version2.3/version
/dependency
dependency
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 bobjolli...@gmail.com wrote:
Ah!! I have just noticed that this new logging regime is
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
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
Lars this seems like a good development to me. I presume we will
still be able to override with an external log4j config. Sometimes
its more convenient to rotate by time (eg month) than by size.
I presume all the exception dumps (ie not real logs) are going to
end up in catalina which is fine.
I think this is a good idea – it can be quite problematic managing log files on
large servers.
………
Regards,
Dapo Adejumo
+2348033683677
Skype : dapojorge
From: Dhis2-devs
[mailto:dhis2-devs-bounces+dapsyjorge=gmail@lists.launchpad.net] On Behalf
Of Lars Helge
Thanks Bob and Dapo.
On Sun, Jun 7, 2015 at 3:50 PM, Bob Jolliffe bobjolli...@gmail.com wrote:
Lars this seems like a good development to me. I presume we will
still be able to override with an external log4j config. Sometimes
its more convenient to rotate by time (eg month) than by size.
On Sun, Jun 7, 2015 at 10:37 PM, Lars Helge Øverland larshe...@gmail.com
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?
15 matches
Mail list logo
