> No.. :-) Well, thanks for not answering :-)
> It's not clear to me exactly WHAT your exact problem is... but can I > hazard a guess that you have your application classloaders configured to > load the webapp classes before the appserver host classes? Not on purpose. Tomcat default perhaps. > IF that is true, then the following occurs [and the ramifications of this > problem extend well beyond commons-logging, it is my opinion that we are > only seeing the tip of this iceburg :-] Yes, I've seen other people not the same thing on Cocoon and Tomcat lists. > First, some nomenclature: > > - let <classLoader>:: be a classloader > - let <classLoader>::<Class> be a <Class> loaded by <classLoader>. > > Note that <classLoaderA>::<YourClass> is NOT the same class as > <classLoaderB>::<YourClass> [the same class resource loaded by two > different classloaders does NOT result in equivalent classes within the > JVM]. > > - let a.jar & b.jar both be in an appserver/lib directory (used > internally > & exposed to applications). > - A class A defined in a.jar. > - A class B, such that B extends on A, defined in b.jar > - A property file, system property, or service definition defines B as "a > desired" implementation of A. > - During host startup, appserver::A and appserver::B are loaded (by > whatever means). > > Now, drop a copy of a.jar into a webapp (classloader hierarchy: > webapp/lib > --(isChildOf)--> appserver/lib). > In a first case, webapp::A is never seen: the class loaders > typically find > appserver::A first. > However, Tomcat (and others) often allow a flag to be set to allow local > classes to be loaded before appserver classes. > > Remember our property file/system property defining B as "the desired" > implementation of A? > > If the system now attempts to locate & load B, without being aware of > which classloader actually found it (A is unaware of whether webapp:: or > appserver:: finds the resource), then in this case it will find & load > appserver::B. > > The class loaded (appserver::B) does NOT extend webapp::A, instead it > extends a different class: appserver::A. Quite. All that said, I'm glad I have something working, and shouldn't have asked the follow up in the first place. Per
