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: more classloader problems.
Date Fri, 07 Jun 2002 14:33:44 GMT
<ras>my comments below </ras>

*******************************************
Richard A. Sitze            rsitze@us.ibm.com
CORBA Interoperability & WebServices
IBM WebSphere Development



                      costinm@covalent

                      .net                     To:      Jakarta Commons
Developers List <commons-dev@jakarta.
                                               apache.org>

                      06/06/2002 04:54         cc:

                      PM                       Subject: RE: Logging: more
classloader problems.
                      Please respond

                      to "Jakarta

                      Commons

                      Developers List"






On Thu, 6 Jun 2002, Richard Sitze wrote:

> I'm new this part of the game (classloaders), but I'm becoming more and
> more aware of the issues.  So, I'd like to add to your question some
bigger
> issues surrounding the placement of commons-logging & other apache
> utility/libraries in web application servers:

There is a simple answer: dump everything in rt.jar, and you'll have no
class loader problems :-) But we have to wait for JDK1.5 for that.

> 1.  How do we find & overload factories (I think this is the issue you
set
> forth below)?
> 2.  How do we find & overload resources in general (NLS
> messaging/properties files)?
> 3.  How do we configure (NOT System properties as we do today - that has
> global implications)?

For 2 - it is _essential_ to use the right ResourceBundle method ( the
one with a loader parameter ), and pass the thread class loader ( or the
loader for a class that is in the same .jar - same thing ). That doesn't
work if you want JDK1.1 compat, in which case all .properties must be in
the top loader.

For 1 - that's pretty much what JAXP and commons-logging is doing to
locate the factory. Or you can use an explicit setting - but make
sure you use the thread class loader for everything.

I don't understand 3, but in general System properties shouldn't be
used for anything but simple apps ( i.e. not in a server env ).
A simple config file ( .properties or xml ) should be used. Of course,
System props are a quick fix and are probably ok for special cases,
but don't expect them to scale.


> The fundamental problem I have is how do we sync classloader mechanisms
> with other algorithms in common use (including the logger):  try resource
> named "resource", then try resouce named "package.resource".  This last
one
> conflicts with classloader in application servers because what we get is:
>      1.  Classloader(s) look for "resource" in application context
>      2.  Classloader(s) look for "resource" in system context
>      3.  Classloader(s) look for "package.resource" in application
context
>      4.  Classloader(s) look for "package.resource" in system context

Not sure who is doing this - are you talking about resource bundles or
something else ? Most packages I know look for a single name.

To get a different behavior you must look explicitely in the class
loaders ( but remember that a child will ask the parent ).

<ras>
It was my understanding that the logic now in LogFactoryImpl::loadClass was
doing just this.  Was this explained to me incorrectly?
</ras>


Costin

>
> but what we want is:
>
>      1.  Classloader(s) look for "resource" in application context
>      2.  Classloader(s) look for "package.resource" in application
context
>      3.  Classloader(s) look for "resource" in system context
>      4.  Classloader(s) look for "package.resource" in system context
>
> I think we may need to design a solution, and - of course - provide an
> implementation as part of the commons project.  If there are answers out
> there, I'd like to see them in a developers guide (common-doc - general
> guidelines?)
> <ras>
>
> *******************************************
> Richard A. Sitze            rsitze@us.ibm.com
> CORBA Interoperability & WebServices
> IBM WebSphere Development
>
>
>
> costinm@covalent.net
> To:      Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> 06/06/2002 01:08
> cc:      List Tomcat-Dev <tomcat-dev@jakarta.apache.org> PM
> Subject: Logging: more classloader problems.
> Please respond to "Jakarta  Commons Developers List"
>
>
>
>
>
>
>
> 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 )
>
> Costin


*******************************************
Richard A. Sitze            rsitze@us.ibm.com
CORBA Interoperability & WebServices
IBM WebSphere Development
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message