No.. :-)
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?
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 :-]
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.
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
"Per Kreipke" <[EMAIL PROTECTED]>
09/25/2002 03:45 PM
Please respond to axis-dev
To: <[EMAIL PROTECTED]>
cc:
Subject: RE: Using Axis SOAP client from Tomcat/Catalina
causes LogConfigurationException...
> Isn't Tomcat just picking up its commons-logging.jar from
> tomcat/server/lib? You might have to see whether Tomcat is stable if
> you replace that with the one from Axis rc1.
Scott,
Thanks for the suggestion. You're right, the one in [tomcat]/server/lib
should be used by the 'kernel'.
I'd tried all of these:
[tomcat]/common/lib [tomcat]/server/lib
1) commons-logging 1.0.1-dev -none-
2) commons-logging 1.1-dev -none-
3) commons-logging 1.0.1-dev commons-logging 1.0.1-dev
4) commons-logging 1.1-dev commons-logging 1.0.1-dev
5) commons-logging 1.0.1-dev commons-logging 1.1-dev
6) commons-logging 1.1-dev commons-logging 1.1-dev
All caused the same error.
The trick turned out to be Richard's note about having a commons-logging
in
your WARs/EARs as well.
When I removed the one in the Cocoon WAR and went back to the ones that
Tomcat and Axis wanted, it worked.
E.g. this worked
[tomcat]/common/lib [tomcat]/server/lib
4) commons-logging 1.1-dev commons-logging 1.0.1-dev
Richard,
Care to comment about what the problem is? I'm a little unclear.
Per
