commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbert Klose" <nkl...@mail.com>
Subject commons-logging & classloading (continued)
Date Thu, 30 Oct 2003 10:21:28 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message