Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49D67DA5.4040201@christopherschultz.net>
Date: Fri, 03 Apr 2009 17:20:37 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [OT] Tomcat error: It is not available the ServletAction
References: <22805251.post@talk.nabble.com>
 			<49D28D0F.4000803@christopherschultz.net>
 			<0AAE5AB84B013E45A7B61CB66943C17215E6DF41B2@USEA-EXCH7.na.uis.unisys.com>
	 		<49D3D27E.1000302@christopherschultz.net> 	<22841693.post@talk.nabble.com>
 		<0AAE5AB84B013E45A7B61CB66943C17215E6E76892@USEA-EXCH7.na.uis.unisys.com>
 	<49D4C863.6020408@christopherschultz.net>
 	<0AAE5AB84B013E45A7B61CB66943C17215E6E76EF5@USEA-EXCH7.na.uis.unisys.com>
 <49D4D5C5.8040503@christopherschultz.net>
 <0AAE5AB84B013E45A7B61CB66943C17215E6F32524@USEA-EXCH7.na.uis.unisys.com>
In-Reply-To: 
 <0AAE5AB84B013E45A7B61CB66943C17215E6F32524@USEA-EXCH7.na.uis.unisys.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 4/2/2009 3:27 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
>> Subject: Re: Tomcat error: It is not available the ServletAction
>> 
>> I think the reason Xerces works within the application's
>> ClassLoader is because of the backward way that webapp ClassLoaders
>> work (load local before parent).
> 
> If you don't mind pursuing this a bit more, I still have some
> concerns about how this can work reliably.  Let's focus on the
> xml-apis.jar for now, which contains numerous classes that are also
> in the 1.5 and newer JREs.  It would seem that if a webapp had its
> own copy of xml-apis.jar, it would load some javax.xml.* classes from
> there, while references in Tomcat's lib directory (including any
> shared jars used by multiple webapps) would resolve those classes
> from rt.jar.  Constructs like instanceof would fail, since they have
> different classloaders.
> 
> Does this just work by luck?

I dunno, but I suspect not ;)

If the application requests any class, presumably it will be loaded from
the xml-api.jar file in the webapp's lib directory. I can imagine that
those classes maintain their own referential integrity, so no classes
end up missing and having to be loaded from the parent ClassLoaders.

Similarly, if Tomcat needs a class, it never goes to the webapp
ClassLoader, so there's no confusion.

The only confusion would occur if you wanted to ask Tomcat to do
something for you and then use XML-related classes. For instance, if
Tomcat provided a service to give you a stream of SAX events, if your
application then tried to use those objects in certain ways, things
would break.

Fortunately, those cases don't crop-up too frequently.

It's possible that the "luck" experienced by webapps like cocoon is by
design: the xml-apis.jar file contains /everything/, including
javax.xml.* so any requests to "the JVM" for an XML parser (for example)
are intercepted by the local libraries and completely fulfilled, whether
those same (or similar) classes are available from the bootstrap
ClassLoader or any other one higher-up in the chain.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAknWfaQACgkQ9CaO5/Lv0PBhtQCgpfrIOkbM5jyNFWXKE+sFmqKA
TQ8AoIGOC671EU8GYeQf1ehlFRjFnTGx
=I/Ib
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org