axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <...@onclave.com>
Subject RE: Using Axis SOAP client from Tomcat/Catalina causes LogConfigurationException...
Date Thu, 26 Sep 2002 19:58:32 GMT
> 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


Mime
View raw message