[slf4j-user] SLF4J and JBoss classloaders

Jacob Kjome hoju at visi.com
Mon Aug 27 18:29:36 CEST 2007


I don't pretend to know a lot about JBoss, specifically, but I'll bet they 
have set up a repository selector and that app logging uses its own logger 
respository; separate from the container.  When you log to the console logger, 
it's logging stuff from one logger repository over the logging configuration 
of another logger repository; hence both the "INFO" and "WARN" entries in one 
logging statement.  INFO is probbly from the container's logger repository and 
and WARN from your app's logger repository.

Now, as far as your logging configuration, have you tried to configure 
manaully or are you counting on automatic configuration occurring?  For logger 
repositories other than the default, automatic configuration will not occur. 
 You need to do it manually.  If, indeed, there are separate logger 
repositories (I think JBoss sets a repository selector at startup, but you 
should double check with JBoss support instead of taking my word for it), you 
won't need to worry about stomping on the containers configuration because 
only your app's logger repository will be affected, not the default logger 
repository used by JBoss.

Ultimately, I suggest posting to a JBoss user list.

Oh, and maybe Ceki can expand on this, there may a problem using separate 
logger repositories with logger wrappers such as commons-logging and SLF4J. 
 For SLF4J, I believe the only safe thing to do is use an SLF4J implementation 
that directly implements the SLF4J API, such as LogBack or Ceki's fork of 
Log4j.  Hopefully Ceki will expand on this issue.

Jake

On Mon, 27 Aug 2007 11:51:20 -0400
  "Paul Oswald" <pauloswald at gmail.com> wrote:
> I'm going to give some background information here but skip to the end
> if to see my slf4j specific question...
> 
> I've just recently switched a large J2SE/J2EE application over to the
> slf4j API. I've also been using the log4j backend so far (previously
> it was jdk logging). When the code is running out of container, I pass
> a command line parameter into the applciation to specify the location
> of log4j.properties and the log file location. That works great.
> 
> When deployed inside JBoss 4.0.4.GA or 4.2.1.GA however, The logging
> message seems to come out twice. A normal server log in JBoss looks
> like this:
> 
> 16:41:57,793 INFO  [TomcatDeployer] deploy, ctxPath=/,
> warUrl=.../deploy/jbossweb-tomcat55.sar/ROOT.war/
> 
> However a line from my application looks like this:
> 
> 11:23:46,806 INFO  [STDOUT] 11:23:46,806 WARN
> [ActionDAO$ActionDAOImpl] This is the message
> 
> Note the source is STDOUT, there are two dates and the catagories are
> different. The log4j pattern string for JBoss is: %d{ABSOLUTE} %-5p
> [%c{1}] %m%n You can see that the first three things are coming out
> ok, however when coming from my app, the message also contains a date,
> catagory and caller information. Modifying JBoss' log4j configuration
> only changes the first three. I've found some log4j.property files
> packed inside of jars we are including into our ear file and removed
> them and that changed how the second part was formatted. It's still
> really weird that the category on some lines are both WARN and INFO
> though.
> 
> So this brings me to my actual question: what is the official
> recommendation for using slf4j with JBoss? They do some interesting
> classloading things to isolate jars from each other so I've gotten
> myself throughouly confused. Currently, I'm packing the slf4j api and
> slf4j-log4j backend into my ear file. I am excluding log4j.jar because
> that should be provided by the server. Why does it seemingly go
> through log4j processing twice?  I suppose I'm supposed to include my
> own log4j.properties file in the ear as well? My understanding was
> that applications should leave the logging decisions up to the
> container and therefore not include a config file, but nothing I do to
> log4j.xml in jboss will make the DEBUG level come out.
> 
> Thanks!
> -Paul
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://www.slf4j.org/mailman/listinfo/user
> 




More information about the slf4j-user mailing list