RE: [OT] Tomcat error: It is not available the ServletAction

["Caldarale, Charles R" <Ch...@unisys.com>]

> 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?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

Re: [OT] Tomcat error: It is not available the ServletAction

[Christopher Schultz <ch...@christopherschultz.net>]

-----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