[logback-dev] [JIRA] Created: (LBCLASSIC-285) Tomcat integration - internal, access and webapps logging
Sébastien (JIRA)
noreply-jira at qos.ch
Thu Jul 28 17:28:51 CEST 2011
Tomcat integration - internal, access and webapps logging
---------------------------------------------------------
Key: LBCLASSIC-285
URL: http://jira.qos.ch/browse/LBCLASSIC-285
Project: logback-classic
Issue Type: Improvement
Components: Other
Affects Versions: 0.9.29
Reporter: Sébastien
Assignee: Logback dev list
I have spend several hours on the last few days to integrate SLF4J with logback in tomcat 6.0.32 ;
My use case is that I want to use slf4j and logback to process all log from tomcat, associated libraries, logback-access and several webapps, each of those webapps having their own configuration file.
I came to logback hoping to have a better experience than with log4j regarding (advertised) context separation and co, but it have been quite more painful than expected.
I have used the solution posted here
https://github.com/grgrzybek/tomcat-slf4j-logback
which is very useful (thanks!) but still suffer from multiple inconveniences.
- It's a bit of a hack ; a very nicely packaged one, but still, having to relocate the package to another namespace and having two copies of the framework is not a smooth integration.
- if you want both tomcat internal -> slf4j -> logback and logback-access, you end up with copies of logback-core and logback-classic in lib/ and suffer from context leakage between webapps which target the common jar
- if you tries to circumvent the former problem with the use of the context JNDI selector, it is picked also by the package relocated tomcat-logback used for internal tomcat logging and go to a bootstrap issue with naming services since it is called early in tomcat start sequence. One could try to patch more the relocated package to rename the property name used to set context selector, but it is adding more complexity and renaming to the relocation hack
- I ended up adding logback-access to the package relocation build and use the renamed version ; it works but hardly elegant and still does not solve other problems.
- If your have an endorsed/ dir in tomcat with some libraries, coming say from apache foundation, that use commons logging, the jcl-slf4j bridge works well but you end up with slf4j and logback in endorsed/ and you also say good by to free context isolation by webapp classloader and copies of logback in each webapp.
- to be sure to choose the good logback configuration for a webapp, I used the ServletContextListener from LBCLASSIC-202 ; a good solution but requires more packaging since it's not present in standard distribution.
I think it could work better with the availability of a bit more Context selector logic, but before digging further, i'm interested to know if there is some work going on in those areas, which I would prefer not to duplicate.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the logback-dev
mailing list