Well put Norbert. I think that since classloading and threads are such complex issues there should be a way to not use the pattern of loading the implementation from thread's context classloader. (Hint to Craig :)
- rami >-----Original Message----- >From: Norbert Klose [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 30, 2003 12:21 PM >To: [EMAIL PROTECTED] >Subject: commons-logging & classloading (continued) > > >Hello, > >i currently use Tomcat 4.1.27 bundled with commons-logging >1.0.3. My own webapp i'm working on also uses commons-logging, >so i include a copy of the jar file into the WEB-INF/lib >directory to be protable to other servlet containers that does >not include the commons-logging package. I found some >discussions in the mail archive that is about commons-logging >and its class loading strategy. But as i could not found an >anwser to my problem, i post my problem here again, hoping to >get a hint for a solution (or maybe to settle on a new consens). > >The problem is, that when tomcat wants to anser a HTTPS >request it instantiates a Http11ConnectionHandler which >processes the connection. >The Http11ConnectionHandler instance itself instantiates a >JSSE14Support class which itself instantiates a >org.apache.commons.logging.Log implementation class. Because >the thread that runs the Http11ConnectionHandler has the >WebappClassloader of my web application as its >context class loader (which ist used by commons-logging to >load the Log implementation (logClass)), BUT the >org.apache.commons.logging.Log interface itself was loaded >from the Common StandardClassLoader, the predicate in >LogFactoryImpl.getLogConstructor() > > (!Log.class.isAssignableFrom(logClass)) > >is false, so that LogFactoryImpl.getLogConstructor() throws a >LogConfigurationException. Because both classes are loaded >from different classloaders. > >IMHO what commons-logging MUST ensure to work correctly is, >that the logClass is loaded from the same classloader than the >Log.class is and this is not guaranteed by the current >implementation! For example > > protected static ClassLoader getContextClassLoader() > throws LogConfigurationException > { > return Log.class.getClassLoader(); > } > >would do. BUT to keep the current implementation what about >changing LogFactoryImpl.getLogConstructor(), so that the >correct predicate is evaluated? > > protected Constructor getLogConstructor() > throws LogConfigurationException { > > ... > > logClass = loadClass(logClassName); > ___logClass___ = >loadClass("org.apache.commons.logging.Log") // >something like this... > if (logClass == null) { > throw new LogConfigurationException > ("No suitable Log implementation for " + >logClassName); > } > if (!___logClass___.class.isAssignableFrom(logClass)) { > ... > } > > ... > > } > >The problem with the current implementation is, that >commons-logging can not rely on the fact that the threads >current context class loader is the classloader that the class >(like the JSSE14Support above) wants to get its logging >implementation from!!! > >Is there a chance to get a consens on that, or at least to >think about changing the current implemetation making it more >reliable ? > >Kindly regards, >Norbert. >-- >__________________________________________________________ >Sign-up for your own personalized E-mail at Mail.com >http://www.mail.com/?sr=signup > >CareerBuilder.com has over 400,000 jobs. Be smarter about your >job search >http://corp.mail.com/careers > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
