commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging] JCL in webapps disabled in JBoss [WAS] requirements and static binding
Date Tue, 21 Jun 2005 06:09:44 GMT
On Mon, 2005-06-20 at 22:46 -0700, Brian Stansberry wrote:
> Maybe a little bit good?  ;-)  With the latest JCL I
> was able to remove the JBoss filter of JCL and get
> logkit logging working for both webapp classes and
> Tomcat's JSPServlet by following the standard steps --
> in WEB-INF/classes and
> logkit jar in the server classpath (thus visible to
> the JSPServlet).  And of course if I just used log4j
> everything ran fine.

That's all good to hear.

> > What this means is that logging performed by shared
> > classes and jboss
> > framework classes isn't going to the logging
> > destination configured in
> > the webapp, but instead the one configured for the
> > container. So while
> > the app will actually run, there is still a major
> > issue if the user
> > really wants/expects that output in their webapp's
> > standard log
> > destination.
> >
> > The correct fix would be to deploy
> > commons-logging-adapters.jar in the
> > webapp instead of commons-logging.jar; then the
> > conflict between Log
> > classes wouldn't occur and they would get both a
> > working app *and* any
> > output generated by jboss/shared classes when
> > context-classpath is set
> > to the webapp would go to the webapp log
> > destination.
> > 
> Yep.  At some point I'll lobby the JBoss folks to
> change their filter so it only blocks LogFactory and
> Log.  This would have the same effect as having users
> deploy commons-logging-adapters.jar.  I doubt they'll
> remove the filter completely with so many copies of
> JCL 1.0.4 or earlier out there. 

Hmm .. yep, that sounds good to me.

> > 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
> > file in their
> > webapp to:
> > * point to a specific logging adapter class, or
> > 
> Since log4j is on the classpath, they'd have to do use
> anyway.

Well, I have a patch to propose which will change that :-)

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 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 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

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?

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 or log4j.xml file inside WEB-INF/classes is completely
ignored in jboss (though picked up in tomcat)?

> <snip>
> > 
> > > But, they'll probably still keep filtering JCL
> > once a
> > > new version of JCL is out in order to keep apps
> > still
> > > using old versions from blowing up.
> > > 
> > 
> > Sorry, I understood your comments to say that they
> > aren't really
> > treating JCL specially, it is just a side-effect of
> > their "Unified
> > classloader" stuff (which sounds a really bad idea
> > to me, by the way).
> > 
> No, the ULR issue was unrelated. If JCL 1.04 is used
> and the filter is disabled, webapp deployment blows up
> when JBoss tries to deploy a custom valve.  This valve
> subclasses Tomcat's ValveBase, so deep in the bowels
> of the code a call is made to LogFactory.getLog(). 
> This call blows up due to incompatible Log interfaces.

Ok, thanks for the info. Though I wish you had used a different metaphor
than bowels blowing up :-)

> > Could you clarify these when you get a moment?
> > * are they treating JCL special (refusing loading
> > from webapp)?
> Yes.  Their webapp classloader specifically prevents
> loading of JCL from the webapp.  Nothing else is
> blocked (although the filter is XML configurable to
> block other packages).
> > * if so, which specific classes are they treating
> > special?
> Everything under org.apache.commons.logging

Ok. I'll add that to the wiki.

> > Thanks a heap for testing this with JBoss - it would
> > not have been good
> > to ship something that they can't use. I'll add them
> > to a list of JCL
> > users somewhere on the wiki.
> > 
> They kinda sorta are; it's crept in as they develop
> projects that have to run outside the appserver.  Deep
> down I get the feeling they'd prefer to just use
> log4j.  JCL 1.1 may go quite a ways to change that
> though.

I think they're on the right path actually. Apps should bind direct to a
logging library. Only libraries that can't control what logging library
their containing app is using should need JCL.

Tomcat has certainly gone the extra mile to give users the flexibility
to select what logging lib will be used with the core engine but I'm not
convinced this outweighs the inconvenience and performance hit.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message