Will Jaynes wrote:
robert burrell donkin wrote:
...
2, a more sophisticated implementation for the loading of the
LogFactory implementation that would try to load the class from the
LogFactory class classloader if the assignment fails. since (at the
moment) we throw an exception
Craig R. McClanahan wrote:
Ojares Rami EINT wrote:
Craig,
Would it be difficult to somehow parametrize the classloading in
commons-logging.
I just commented out small portion that resorts to thread classloader.
To me it seems that it would be very trivial to give the user possibility
to
Todd,
With the jars configured as you describe, how do you configure different
logging properties for each web app?
Todd Jonker wrote:
Will, what I suggest is placing c-l.jar in your server-level
classpath, or in the JVM classpath... and **nowhere else**. If you
have any custom Logs or
Why does LogFactoryImpl in commons-logging
try to load the Log implementation class first
from thread classloader and then loader that loaded this class?
Is there some kind of design pattern behind this?
One very common :-) use case for commons-logging is inside web
applications, where the