commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <>
Subject Re: [logging] LoadTest
Date Tue, 31 May 2005 04:22:29 GMT

--- robert burrell donkin <> wrote:
> On Mon, 2005-05-30 at 18:40 +1200, Simon Kitching
> wrote:
> > On Sun, 2005-05-29 at 21:17 -0700, Brian
> Stansberry wrote:
> > > I've been testing my new implementation of
> > > LogFactoryImpl and it's looking good except it
> fails
> > > the "testInContainer" test of o.a.c.l.LoadTest. 
> This
> > > test sets up a parent-last (aka child-first)
> > > classloader hierarchy that has JCL and a class
> that
> > > calls JCL in the child.  JCL is also visible in
> the
> > > parent.  It then performs various tests, setting
> the
> > > thread context class loader to various values
> and
> > > trying to log.
> > > 
> > > This test is designed to fail if logging
> succeeds when
> > > the TCCL is set to the system classloader or the
> > > parent classloader.  
> > > 
> > > The old implementation of LogFactoryImpl does
> throw a
> > > LogConfigurationException in this situation, as
> > > discovery finds an adapter in the parent that is
> > > binary incompatible with the LogFactoryImpl in
> the
> > > child.
> > 
> > I suspect it actually fails because LogFactoryImpl
> finds Log4JLogger in
> > the parent, but log4j classes are not in the
> parent. 

Your new diagnostics are really helpful here.  They
show exactly what happens.

First, by the design of the test JCL has to be visible
to "parent" classloader, which is the test case's
classloader.  This is because the child-first loader
the test creates actually uses the "parent"
classloader to find the class file.

When I run this either using ant or Eclipse, the
system classloader and the test case's loader are the
same (i.e. the testing framework does not add a

LogFactory and LogFactoryImpl are loaded by the child

TCCL is set to the parent/system.

Discovery analyzes the parent classloader.  If
log4j.jar is present, it discovers log4j.  If not, it
discovers jdk14.

Discovery fails because Log interface implemented by
discovered adapter is defined by the parent, while
LogFactoryImpl is defined by the child.

> i suspect that the majority opinion was that JCL
> should refuse to run in
> containers which didn't obey the rules. therefore,
> this was a legitimate
> test. however, the current consensus is that (with
> hindsight) this
> original decision was wrong. it was a semantic bug.
> i really cannot
> think that any code could reasonably rely on JCL
> throwing a runtime
> exception whenever exotic context classloader
> configurations are
> encountered.

> i agree that it should be updated. 
> > An updated test really ought to verify that when
> context=system, logging
> > falls back to jdk14 (when running with java14) or
> to SimpleLog. But if
> > this is too much work, just asserting that logging
> still works would be
> > ok by me.
> +1

With the new code (aka rev 3b), if log4j.jar is
visible to the parent classloader it will be
discovered.  Assume the scenario above; log4j.jar is
visible tot the parent so discovery using the bogus
TCCL finds a binary incompatible Log4jLogger.  This
error will be caught, and an attempt will be made to
load Log4jLogger using the LogFactoryImpl's loader
(the child).  This will succeed, because log4j.jar can
be loaded via parent delegation.

I'm not sure if this is a flaw (maybe the child really
wanted jdk logging, and we're giving them log4j), but
basically we're discovering the log method made
available via the TCCL.

In any case, I don't think we can test for jdk or
SimpleLog being discovered; we can only test if
logging worked.


Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we.

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

View raw message