commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject [logging] history lessons revisited
Date Thu, 27 Jan 2005 22:52:02 GMT
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 )

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?

Richard A. Sitze
IBM WebSphere WebServices Development
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message