commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Logging: more classloader problems.
Date Thu, 06 Jun 2002 20:27:59 GMT
On Thu, 6 Jun 2002 costinm@covalent.net wrote:

> Date: Thu, 6 Jun 2002 11:08:10 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Cc: List Tomcat-Dev <tomcat-dev@jakarta.apache.org>
> Subject: Logging: more classloader problems.
>
>
> 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 )
>

+1 for leaving commons-logging.jar with the same contents and adding
commons-logging-api.jar with just the API classes.  That way, we won't
disrupt anyone who is successfully using the existing approach.

+1 for a dot release with both, once you're satisfied that it works for
the problem case described.

> Costin
>

Craig


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message