robert burrell donkin <[EMAIL PROTECTED]> 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
