> -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > On Mon, 22 Apr 2002, Scott Sanders wrote: > > 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.
How would this break that situation. It is if and only if we want to use the default LogFactory which should come from the same CL as LogFactory itself, correct. Again, this is only when using the default o.a.c.l.i.LogFactoryImpl. All other cases would still use the context CL. Scott > > > Any questions, comments, suggestions? > > > > If not, I will commit this. > > > > Scott > > > > Craig > > > > Index: src/java/org/apache/commons/logging/LogFactory.java > > =================================================================== > > - factory = newFactory(FACTORY_DEFAULT, classLoader); > > + factory = newFactory(FACTORY_DEFAULT, > > LogFactory.class.getClassLoader()); > > } -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
