--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi Brian,
>
> On Sun, 2005-06-19 at 16:22 -0700, Brian Stansberry
> wrote:
> > Had a chance to check this out, and the problem is
> > because JBoss/Tomcat uses commons-logging.jar
> instead
> > of the commons-logging-api.jar used by standalone
> > Tomcat. When a webapp is deployed JBoss also
> deploys
> > container code that executes when the webapps
> > classloader is the TCCL (e.g. a valve that helps
> > support the JACC spec). This code fails with
> > LogConfigurationExceptions due to incompatible Log
> > interfaces.
> >
> > JBoss can't just use commons-logging-api.jar as
> they
> > use log4j for server logging.
>
> Yep. Normally, a tomcat adminstrator will also
> replace the
> commons-logging-api.jar with the full jar in order
> to get better control
> over tomcat's output.
>
> >
> > Good news is, the version of JCL in svn fixes this
> > problem :)
>
> Well, I don't think it should be regarded as such
> great news (though
> it's what we deliberately implemented :).
>
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 --
commons-logging.properties 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.
> 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.
BTW, most JBoss framework code will only log to Log4j.
Most JBoss code uses an internal logging abstraction
that discovers log4j if it's on the classpath (which
it always is inside the appserver). There are a few
modules that use JCL because they are supported as
standalone products that can run outside the
appserver. It was these modules that failed without
the JCL patch you just applied.
> 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.
> I can live with that though; we can just make it
> point#1 in the new jcl
> FAQ that having a commons-logging.properties file
> specifying an explicit
> logadapter is a very good idea, and the very first
> thing to do when
> anything unexpected is happening.
>
+1
> And at least users who don't care about logging
> aren't brought to a grinding halt.
+1
<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.
> 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
> * which versions of jboss have this "unified
> classloader" stuff?
>
The 4.0 and 3.2 series and I believe 3.0 as well.
> > BTW, in their nightly builds they've started using
> a
> > patched version of JCL whose LogFactory uses a
> > WeakHashMap instead of a Hashtable. This fixes
> memory
> > leak problems in their unit tests.
>
> Then that seems good support for bundling
> WeakHashtable into the main
> distribution. I'll go ahead and do that, and may as
> well get rid of the
> optional jar completely as there's nothing else in
> there worth keeping.
I kinda liked your ServletContextListener ;)
> Perhaps it's worth comparing your WeakHashtable with
> their patch to see
> if there's anything to be learned there?
>
They just replaced the factories Hashtable with a
WeakHashMap (wrapped by
Collections.synchronizedMap()).
> Actually, maybe we should be discussing whether JCL
> needs to support
> JVM1.1 or not. If it doesn't then that weakref stuff
> becomes a lot
> easier (and hence more reliable). JCL hasn't
> supported JVM1.1 for a very
> long time now (as we found accidentally....) though
> it probably isn't
> too hard to restore 1.1 support. In fact, if someone
> turned up who
> actually needed JVM1.1 support we could probably fix
> this fairly
> quickly. So maybe staying with WeakHashtable is a
> good idea..
>
I think it's probably best. If we make big changes
like those on the DON_QUIXOTE branch, that could be a
good chance to factor out code for JDK 1.1.
>
> 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.
My pleasure doing the JBoss testing. I'll try to take
that on as a regular thing when releases are
approaching. I pretty regularly do work on JBoss
stuff, so I've always got their code on my machine.
Brian
____________________________________________________
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
