commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: commons-logging & classloading (continued)
Date Tue, 18 Nov 2003 22:16:28 GMT
Forgive me for jumping in with a comment, I have the interest if not the
experience (at least not of the rest of this thread.) I'm wondering ... is
the issue loading the local webapp's version of commons logging, or getting
to it's configuration? Assuming a robust/stable interface/implementation of
CL, I have to assume the latter. Having a copy of CL bundled with the webapp
ought be just a "fallback".

So, does that change the problem from class loading to resource loading? Is
it possible to get to the webapp's resource, [whereas getting to the webapps
classes might lead to a Link error.] I don't know the details of resource
loading, but I wonder if it is less of a rats nest than class loading. I
wonder if one could as for local-commonslogging.properties and if not found
go for commonslogging.properties [shipped with CL or whatever.] Unlike
classloading, I assume one can have multiple resources in memory more
easily.

That said, I don't know if one can teach the log load to detect that a
webapp was just loaded (if the Log class is already in memory). I assume
this is doable though.

Just a random thought...

regards

Adam
----- Original Message ----- 
From: "Richard Sitze" <rsitze@us.ibm.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Tuesday, November 18, 2003 12:51 PM
Subject: RE: commons-logging & classloading (continued)


> So, I'm coming into this a bit late and all, and I know a few others have
> been looking at this over the past few weeks...  hope this does more than
> just add fuel to the fire.
>
> commons-discovery was created to address the classloader usage patterns
> being discussed : how to discover an implemention for a given interface.
>
> Commons-discovery was explicitly designed to be a general replacement for
> LogFactory - I'd like to see LogFactory eliminated entirely from
> commons-logging.
>
> On the surface, you may not find that commons-discovery does anything more
> than LogFactory.  Underneath, it's a set of tools that let you setup your
> own patterns.
>
>
> That said:
>
> LogFactory was designed to work in a J2EE environment by dropping it into
> the "Server" level.  It also functions quite well embedded into the
> application.
>
> As is being discovered, it doesn't work so well if you want some hybrid of
> that.  It's a known problem, and I'm sorry to say I simply don't see ANY
> straight forward fix available - particularly by working with the
> ClassLoaders.  The following was proposed:
>
>
>      if (!Log.class.isAssignableFrom(logClass)) {
>          // Plan B. Bend over backwards to continue
>          Class logInterface =
>              LoadClass("org.apache.commons.logging.Log");
>          if (logInterface == null) {
>              throw new LogConfigurationException
>                  ("Log interface can not be found");
>          }
>          if (!logInterface.isAssignableFrom(logClass))
>              throw new LogConfigurationException
>                  ("Class " + logClassName + " does not implement Log");
>      }
>
>
> The situation:
> - logClass bundled into a webapp.
> - commons-logging bundled into a webapp, with "local" configuration
> settings.
> - commons-logging bundled into the webserver, with "global" configuration
> settings.
>
> Clearly logClass, which implemented the "local" copy of Log, failed to
> load because it doesn't implement the (expected) "global" copy of Log.
> Calling LoadClass("org.apache.commons.logging.Log") will only return the
> "global" copy - classloaders (by design) always defer to parent
> classloaders.  In this case, the web-app classloader gives the server
> classloader first crack at loading Log.  You simply don't have anyway to
> "see" the local copy.... that's the fundamental problem.
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
>
>
> It's a kind of growing pain with the success of Commons.
> Some servers have some commons jars while others not. In the
> application you always include jars you needed. At the end of
> day, situation like that seems inevitable, not just logging,
> not mention the version problem.
>
> Is it possible some standard be set or a classloader component
> in Commons?
>
> - sean
>
> --- Ojares Rami EINT <Rami.Ojares@elisa.fi> wrote:
> > 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:nklose@mail.com]
> > >Sent: Thursday, October 30, 2003 12:21 PM
> > >To: commons-dev@jakarta.apache.org
> > >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: commons-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
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