[slf4j-user] Per-web-app logging with jars on the server's classpath

Jacob Kjome hoju at visi.com
Sun Mar 18 19:46:55 CET 2007


At 05:56 AM 3/18/2007, you wrote:
 >Jacob Kjome <hoju <at> visi.com> writes:
 >
 >>
 >> That's an interesting finding.  When it worked for you, did you have
 >> to use the WEB-INF/weblogic.xml file I suggested might be necessary
 >> in a previous email, or did it work without that? BTW, where do you
 >> put commons-logging.jar and slf4j jars?  Are they in the server
 >> classpath as well alongside log4j.jar?  Actually, I can't see how it
 >> couldn't be.  If your framework extends Spring, Spring jars and their
 >> dependencies would also have to be on the server classpath.  Given
 >> this, I hope all the libraries use non-static loggers.
 >
 >I did not have to use weblogic.xml - I only had to put the 2 env-entries
 >into
 >web.xml.
 >

good to know

 >All of the JAR files are on the server's classpath along with log4j.jar, and
 >Spring classes do not use static loggers (which is good for me!).  Instead of
 >the official commons-logging.jar I was using jcl104-over-slf4j-1.3.0.jar, but
 >now because of the problem I'm having using JCL, I may have to 
write my own JCL
 >implementation to use log4j 1.3 directly instead of SLF4j.  I just downloaded
 >JCL 1.1 source but it appears to still use log4j 1.2.
 >

I thought they did something to make it compatible with 1.3, but I 
could be mistaken.  I suggest asking on the Jakarta Commons list.

 >>
 >> This is getting out of my area of expertise.  I'm a Log4j developer,
 >> not an SLF4J developer.  Ceki may have some ideas here.  I find it
 >> odd that wrappers would have an effect whatsoever.  If all they are
 >> doing is forwarding to Log4j then, ultimately, Log4j should be
 >> controlling which logger repository is used.
 >>
 >> BTW, do you have a default config file (log4j.properties or
 >> log4j.xml) in the server's classpath that Log4j uses to configure its
 >> default logger repository?  If so, does it point to the same Log file
 >> as appA?  If it does, then that could be the culprit.  Wrapped
 >> loggers might be logging to the default logger
 >> repository.  Otherwise, I find it odd that the repository selector
 >> would be arbitrarily (but consistently) choosing a non-default logger
 >> repository to log to.
 >
 >I do not have a default log4j.properties or log4j.xml file anywhere on the
 >classpath.
 >

...and hopefully no other library does either.  Which is why I 
suggest putting a default config file (log4j.xml, preferably) in the 
server classpath for those cases where no other logging might happen 
outside the context of your application.  An example could be some 
back end process that gets triggered asynchronously, so the code 
isn't run within the scope of your webapp.

And I'm still curious how, when the wrapper is being used to front 
Log4j, the logging is going to "appA"'s logger repository.  How would 
it get chosen as the default rather than the default logger 
repository?  That's a little bizarre.

 >We've definitely made progress and I can now write log messages to separate
 >files as needed.  Now I want to get JCL working correctly.  I've made some
 >progress with that already - I started with SLF4JLog and
 >SLF4JLogFactory, copied
 >them to MyFrameworkLog and MyFrameworkLogFactory, cut out all references to
 >SLF4J, and made them use Log4J directly.  JCL writes to separate 
log files this
 >way, but the log messages include the incorrect class name in the conversion
 >layout.
 >
 >Here's the conversion layout:
 >log4j.appender.file.layout.ConversionPattern=%d{dd MMM yyyy HH:mm:ss,SSS} %5p
 >%C{1} - %m%n
 >
 >The log entries from a class called "UserFormController" should 
look like this
 >(and does if I use Log4j directly without JCL):
 >17 Mar 2007 13:00:39,087  INFO UserFormController - entering
 >formBackingObject()
 >
 >using the JCL with my custom Log4j Log and LogFactory, it looks like this:
 >17 Mar 2007 13:00:39,087  INFO MyFrameworkLog - entering formBackingObject()
 >
 >So I need to figure out where %C is turned into a classname... any thoughts?
 >

How are you calling Log4j?  Do you use the methods that take an FQCN 
(fully qualified class name) as the first parameter?  The FQCN should 
be that of the wrapper class used to call Log4j, or 
MyWrapper.class.getName() + ".".  Notice the appending of the period 
at the end of the FQCN.  This is recommended practice, though I don't 
recall the exact reason why it is recommended?  Maybe Ceki can chime 
in on that?


Jake

 >Thanks
 >Mark
 >
 >_______________________________________________
 >user mailing list
 >user at slf4j.org
 >http://www.slf4j.org/mailman/listinfo/user




More information about the slf4j-user mailing list