Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 75627 invoked from network); 6 Jun 2002 21:55:06 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Jun 2002 21:55:06 -0000 Received: (qmail 18913 invoked by uid 97); 6 Jun 2002 21:55:09 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 18879 invoked by uid 97); 6 Jun 2002 21:55:07 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 18858 invoked by uid 98); 6 Jun 2002 21:55:06 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Thu, 6 Jun 2002 14:54:52 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Jakarta Commons Developers List Subject: RE: Logging: more classloader problems. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 ). 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?) > > > ******************************************* > Richard A. Sitze rsitze@us.ibm.com > CORBA Interoperability & WebServices > IBM WebSphere Development > > > > costinm@covalent.net > To: Jakarta Commons Developers List > 06/06/2002 01:08 > cc: List Tomcat-Dev 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 > > > > > > > -- > To unsubscribe, e-mail: org> > For additional commands, e-mail: org> > > > --1__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F > Content-type: text/html; charset=US-ASCII > Content-Disposition: inline > > 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:
>
> 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)?
>
> 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
>
> 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
> height="16" alt="">costinm@covalent.net
>
>
> > cellpadding="0"> > >
width="72" alt="">
>
> >
    >
      >
        >
          costinm@covalent.net >

          06/06/2002 01:08 PM
          > Please respond to "Jakarta Commons Developers > List"

        >
      >
    >
>
>
> 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 )
>
> Costin
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta. > apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org > >
>
> > > --1__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F-- > > > --0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F > Content-type: image/gif; > name="graycol.gif" > Content-Disposition: inline; filename="graycol.gif" > Content-ID: <10__=09BBE143DFF5E87F8f9e8a93df938@us.ibm.com> > Content-transfer-encoding: base64 > > R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu > > ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 > > --0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F > Content-type: image/gif; > name="ecblank.gif" > Content-Disposition: inline; filename="ecblank.gif" > Content-ID: <20__=09BBE143DFF5E87F8f9e8a93df938@us.ibm.com> > Content-transfer-encoding: base64 > > R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 > > --0__=09BBE143DFF5E87F8f9e8a93df938690918c09BBE143DFF5E87F-- -- To unsubscribe, e-mail: For additional commands, e-mail: