--- Simon Kitching <[EMAIL PROTECTED]> wrote: > On Mon, 2005-06-20 at 22:46 -0700, Brian Stansberry > wrote:
<snip> > > > > Of course because the error is now suppressed, > > > people won't get any hint > > > that the logging output is getting diverted to > an > > > unexpected destination > > > - unless they explicitly use a > > > commons-logging.properties file in their > > > webapp to: > > > * point to a specific logging adapter class, or > > > * turn off ALLOW_FLAWED_LOG_HIERARCHY > > > > > > > Since log4j is on the classpath, they'd have to do > use > > commons-logging.properties anyway. > > Well, I have a patch to propose which will change > that :-) > Related to the comment you just added to LogFactoryImpl? > But the issue is still that users can get the *wrong > copy of log4j*. If > they get the one in their webapp, then it will use a > log4j.properties or > log4j.xml file in the webapp to configure itself. If > they get the one in > the server, then it will have already configured > itself from the > log4j.properties or log4j.xml file in the server > classpath and will > totally ignore the webapp's config file. > > And if code in the webapp gets the webapp copy of > log4j but code in the > shared classpath called on behalf of the webapp (ie > with context > classloader set) gets the server copy of log4j then > logging from those > calls will go to the server. That's specifically why > it's good to try to > load the log adapter from the context classpath; if > it gets log4j from > there then logging by shared classes operating on > behalf of a webapp use > the log4j classes which were configured via a > webapp-specific config > file. > > Recent versions of log4j support this thing called a > "context hierarchy" > which means that even when deployed in a shared > classpath, log4j will > try to use config files from the context classpath. > This will resolve > the issue - but requires the container to set this > all up first. Do you > have any idea whether JBoss uses this log4j feature? > Thanks for pointing this out. I while back I dug into the log4j code and saw them using the context classpath. Didn't know it was a new thing. To answer your question, at least beginning with JBoss 4.0.1 they use it. I know because the app I work on at my job uses it to separate our logging from the server's. (We put a log4j.xml in WEB-INF/classes). In JBoss 3.2.5 including log4j.xml in the webapp does not work. And now I know why. > Hmm..given that JBoss filters out all jcl classes by > default, isn't this > painfully obvious with jboss? How on earth is a > webapp supposed to > configure its JCL logging when running inside > jboss?? Surely any > log4j.properties or log4j.xml file inside > WEB-INF/classes is completely > ignored in jboss (though picked up in tomcat)? > The filtering of JCL is a new thing (added in 4.0.2) and in the 4.0 series configuring log4j from the context classpath works. Last night I also noticed avalon-framework.jar is on the server classpath. Don't know why, but may have something to do with making it available to shared classes if people specify it in a webapp. Brian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
