commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] history lessons revisited
Date Tue, 01 Feb 2005 20:27:24 GMT
robert burrell donkin <rdonkin@apache.org> wrote on 01/30/2005 04:09:54 
PM:

> 
> On 28 Jan 2005, at 20:15, Richard Sitze wrote:
> 
> > [re-send.. I don't see this picked up... hmmm]
> >
> >
> > Once, a long long time ago... someone wrote:
> >
> >> The problem: it won't work if commons-logging.jar is installed in the
> >> parent class loader, and log4j.jar ( or another logger ) is installed
> >> in a child loader ( like WEB-INF/lib ).
> >>
> >> What happens:
> >> - the factory uses the thread class loader to check if the log4j
> >>  ( or any other impl. ) exists ( and it does ).
> >>
> >> - it creates an instance of the Logger adapter. This will be created
> >>   using parent loader ( the one that loads commons-logging ).
> >>
> >> - the Logger instance makes references to Category or other classes
> >>   that are used in it's implementation. End of story, since the class
> >>   loader can't find the reference.
> >>
> >> This works fine for JAXP because the adapter for a parser is part of
> >> the parser jar. It doesn't work for c-l because the adapter is in the
> >> root loader ( with the API), not with the logging impl.
> >>
> >> That doesn't affect people who just use a single logger or can put
> >> the logger impl. in the same place with common-logging. It only 
affect
> >> containers like tomcat, when you want to let each webapp use it's own
> >> logger impl. of choice.
> >>
> >> I tried all kind of introspection games, it won't work. The only
> >> solution I see is to make sure the adapters are in the same place
> >> with the logger.
> >>
> >> Solution:
> >> Split commons-logging.jar in commons-logging-api.jar ( only the API
> >> and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
> >>
> >> Alternatively, leave commons-logging.jar as it is and create a second
> >> commons-logging-api.jar.
> >>
> >> The -api will be included in the common loader. Each webapp will have
> >> to include commons-logging.jar ( or -impl ), and it's own logger.
> >>
> >> Or course, the best would be to have the adapter included in the
> >> logger impl.
> >>
> >> What do you think ? Craig, Remy can we make another c-l dot release
> >> with this change ? ( I'll do some more testing to see how it works )
> 
> i suspect that this solution may run into some issues with the way that 
> JCL 1.0.x is factored into API and implementation. of course, i'd be 
> glad for someone to prove me wrong ;)
> 
> > And now I ask... is it *ever* appropriate to use to the Thread Context
> > Class Loader for our "auto detect" of impls?  The correct class loader
> > to use is *always* the classloader used to load the wrapper.  No?
> 
> yes: the test should always be performed with the classloader that used 
> to load the wrapper.

Ok, so this was my main focus/point on this topic.  I know we use the 
context class loader for some situations [and it's appropriate to do so]. 
Beginning to recognize that we don't need to take a 'carte-blanc' toward 
this.

Is this something you'd like to capture for the 1.0.5 release?  It 
resolves point "A" in my summary of class loader issues.

> (i seem to recall a discussion about this on the commons logging list 
> sometime in the last few months but i can't remember whether any subtle 
> issues emerged...)
> 
> it may be appropriate to use the thread context class loader if that's 
> the one to be used to load the wrapper. i wonder whether it might make 
> sense for logging implementations to be passed in the classloader which 
> should be used to load whatever classes they required...
> 
> - robert

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message