On Thu, 6 Jun 2002 [EMAIL PROTECTED] wrote: > Date: Thu, 6 Jun 2002 11:08:10 -0700 (PDT) > From: [EMAIL PROTECTED] > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > Cc: List Tomcat-Dev <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
