Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 86744 invoked from network); 7 Jun 2002 14:54:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Jun 2002 14:54:17 -0000 Received: (qmail 18127 invoked by uid 97); 7 Jun 2002 14:53:40 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 18032 invoked by uid 97); 7 Jun 2002 14:53:40 -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 17939 invoked by uid 98); 7 Jun 2002 14:53:39 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Subject: RE: Logging: more classloader problems. To: commons-dev X-Mailer: Lotus Notes Build V60_M13_04302002 Pre-release 2 April 30, 2002 Message-ID: From: "Richard Sitze" Date: Fri, 7 Jun 2002 09:33:44 -0500 X-MIMETrack: Serialize by Router on D04NM201/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 06/07/2002 10:52:45 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBE142DFDC70E08f9e8a93df938690918c09BBE142DFDC70E0" Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --0__=09BBE142DFDC70E08f9e8a93df938690918c09BBE142DFDC70E0 Content-type: text/plain; charset=US-ASCII my comments below ******************************************* Richard A. Sitze rsitze@us.ibm.com CORBA Interoperability & WebServices IBM WebSphere Development costinm@covalent .net To: Jakarta Commons Developers List 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 ). It was my understanding that the logic now in LogFactoryImpl::loadClass was doing just this. Was this explained to me incorrectly? 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 ******************************************* Richard A. Sitze rsitze@us.ibm.com CORBA Interoperability & WebServices IBM WebSphere Development --0__=09BBE142DFDC70E08f9e8a93df938690918c09BBE142DFDC70E0--