On 18 Nov 2003, at 19:51, Richard Sitze wrote:
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.
i don't think that there's any chance of that. (i also suspect that there's very little chance of adding a core dependency upon a discovery replacement.)
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.
i think that the problems reported with classloaders mostly fall into a few distinct categories. some are due to misguided administration policies (and we can do very little about that). some are down to the conflict between the behaviour required for correct function when logging in modern servlet containers and different classloader environments. other are down to the need for hybrid uses (to borrow your phrase from later in the email - i have the advantage of being able to read it all before replying :)
we can do very little about misguided administration policies but there are things we can do about the others.
i think that offer different LogFactory implementations are part of the solution. a user operating in an unusual environment would then be able to choose to run another implementation by adding the appropriate -D switch on the command line. i'd support an optional discovery based LogFactory implementation (but not a core one). even if users didn't use it directly, it would give them a positive example they could based more sophisticated discovery-based solutions on. fancy giving this a go?
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.
i'm not sure that it is in this case. i have a feeling that some of the reports came from containers which used other (older?) classloading strategies. that's why some people have reported some success when loading from the LogFactory.getClassloader.loadClass(). i agree that it's not a proper solution but it'd probably make life a little easier for people using containers with odd (or older) classloading strategies.
BTW one of my person bugbears is that commons-logging throws exceptions when logging configuration fails. there is no technical reason why we could not give the user an system property that suppresses all exceptions and uses a very simple default logger. comments anyone?
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
