7

During deployment of a web application (in test environment) on customer site we encountered a problem with logging of the application. I'll shortly try to describe the current situation:

  • Implementation uses Logger retrieved by java.util.logging and apache.commons.logging.
  • In the deployed packages exists a commons-logging.properties pointing to JUL.
  • Application is running on Tomcat 6.x

The customer decided that he wants to use Log4J on tomcat and configured it so it works (generally) - of course it's not working for the mentioned application.

As it seems that we need to change logging implementation anyway - i wanted to ask you for some best practices on how to implement logging in a web application. Following things should be possible:

  • Customer needs to be able to change log-level without modifying anything in the *.war-file. -> If he would have to modify the war-file he would have to do this for every new build ...
  • It should be possible to have some kind of rolling-file-logging (e.g.: max 10 files with max. 10mb each) - of course it should also be up to the customer to define and change this setting ...
  • As another customer might want to use standard JUL-logging instead - I'd of course prefer to not hard-code the preferred library (Log4J in this case).
dpr
  • 93
  • 2
  • 6

2 Answers2

6

Customer needs to be able to change log-level without modifying anything in the *.war-file.

You can put logging framework configuration file (log4j.xml or logback.xml) outside of the WAR file. Also supports automatic reconfiguration when this file is changed.

It should be possible to have some kind of rolling-file-logging

Both and Logback support rolling back of files, both based on size and date, see e.g. RollingFileAppender.

As another customer might want to use standard JUL-logging instead - I'd of course prefer to not hard-code the preferred library (Log4J in this case).

is fundamentally broken, use instead. Then you simply put different implementations on your CLASSPTH. Also the SLF4J API is quite pleasent.

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • Thanks for your answer! Regarding the "ou can put logging framework configuration file (log4j.xml or logback.xml) outside of the WAR " -> how are the than binded to the application? – dpr May 31 '12 at 18:59
  • @dpr: you need to put two JARs next to SLF4J API: target logging framework and so-called binding. The latter is a very small JAR that instructs the API which logging framework to use. See: http://www.slf4j.org/faq.html#where_is_binding – Tomasz Nurkiewicz May 31 '12 at 19:02
2

You should take a look at SLF4J. It is essentially a wrapper that allows the end user to drop in what ever logging library they want (for the most part).

While I have not tried, they even have a migrator tool that should help changing over your code to use it.

Jacob Schoen
  • 14,034
  • 15
  • 82
  • 102
  • But in this case the user would still have to modify the WAR-file, wouldn't he? I mean - we would ship it with maybe JUL-logging customer1 wants to have Log4J and customer2 logBack... – dpr May 31 '12 at 18:54
  • SLFJ allows them to drop in what ever logging library they want to. – Jacob Schoen May 31 '12 at 18:55
  • @SJuan76: The reason why the customer choose Log4J is the flexiblity in matter of configuration... starting from rolling-file-logging to further possiblities I don't know in detail – dpr May 31 '12 at 18:56
  • @dpr no you should not need to have a new build, you should be able to include the logging library in the Tomcat global classpath, and I think you can place the configuration files there to. But honsetly I have not played with tomcat in a while, so I could be wrong on that. – Jacob Schoen May 31 '12 at 19:00