I think this is a related issue, but I have not had time to investigate
fully, so sorry if this is OT. I have an app, that using
commons-logging in some of its dependencies, which is configured to use
log4j. As commons-logging is in <tomcat>/common/lib, I have to put
log4j in common/lib as well or I get ClassNotFoundException's. Now if I
have multiple contexts with similar webapps, the log files get munged
together/corrupted.
This might be more an issue with tomcat in that it should not be putting
a library like logging into a classpath used by webapps. But is there
some way of configuring/using commons logging so that a component that
is used in multiple places within an application can log to the location
appropriate for each of its uses without relying on classloader imposed
separation. It does not seem that static factory methods like
Log.getLogger(String) or Category.getInstance(String) are the best way
to invoke logging within a component meant to be used within a larger
system.
john mcnally
"Craig R. McClanahan" wrote:
>
> On Mon, 22 Apr 2002, Scott Sanders wrote:
>
> > Date: Mon, 22 Apr 2002 09:48:54 -0700
> > From: Scott Sanders <[EMAIL PROTECTED]>
> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> > To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> > Subject: [LOGGING] ClassLoader Problems
> >
> > Hi all,
> >
> > I am working on vindico, a replacement for Alexandria over in the
> > Alexandria CVS, and I am using commons-digester, which in turn uses
> > commons-logging.
> >
> > When running Vindico as an Ant task, it starts running and then says
> > that it cannot find the LogFactoryImpl class.
> >
> > I have traced this down to the getClassLoader() function in LogFactory,
> > which returns the Thread.getContextClassLoader() if there is one.
> >
> > The problem that I have is the LogFactoryImpl class is in the same class
> > loader as LogFactory, so I am suggesting a change to LogFactory, such
> > that the default class loader is used. Patch is below. Are there other
> > problems that this does not address?
> >
>
> Haven't looked at the patch yet, but from your description it sounds like
> this would break the use of commons-logging in a servlet container where
> the commons-logging.jar file was in a shared directory and the desired
> custom LogFactory implementation class was in the webapp. Please make
> sure that this use case works correctly.
>
> > Any questions, comments, suggestions?
> >
> > If not, I will commit this.
> >
> > Scott
> >
>
> Craig
>
> > Index: src/java/org/apache/commons/logging/LogFactory.java
> > ===================================================================
> > RCS file:
> > /home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/Lo
> > gFactory.java,v
> > retrieving revision 1.6
> > diff -u -r1.6 LogFactory.java
> > --- src/java/org/apache/commons/logging/LogFactory.java 15 Mar 2002
> > 22:57:36 -0000 1.6
> > +++ src/java/org/apache/commons/logging/LogFactory.java 22 Apr 2002
> > 16:48:12 -0000
> > @@ -347,7 +347,7 @@
> >
> > // Fourth, try the fallback implementation class
> > if (factory == null) {
> > - factory = newFactory(FACTORY_DEFAULT, classLoader);
> > + factory = newFactory(FACTORY_DEFAULT,
> > LogFactory.class.getClassLoader());
> > }
> >
> > if( props!=null ) {
> >
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
