Simone Bordet has finally guilted me into looking more closely at the
many class loading issues associated with commons logging.
As a result, I think I have found an interim solution to avoid these
issues in the next Jetty 5 release.
The main problem with commons logging is the discovery mechanism.
While Jetty has a very flexible classloader, it still fails with
commons logging discovery when a webapp calls back to API in
Jetty for the first time and new classes are loaded.
So the solution I have come to is to either totally avoid
commons discovery and directly call the Jetty logging factory,
or to do the factory discovery once and only once and them use
that discovered factory for all of Jetty.
Do do this, Jetty now calls it's own LogFactory facade.
If the system property org.mortbay.log.LogFactory.noDiscovery
is true, then a static instance of the Jetty Log factory is used.
if it is false (or not set), then normal commons discovery is performed
once, and the resulting factory used for all of Jetty.
With this change, I have been able to configure Jetty to use its
own commons logging implementation and for a webapp to use a different
instance of commons logging which uses log4j.
This is checked into CVS now. Your milage may vary, so I'd really appreciate
if people could test CVS head before I do a RC release this weekend.
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________
jetty-discuss mailing list
[hidden email] https://lists.sourceforge.net/lists/listinfo/jetty-discuss