Hi chris,
Thanks for you support.
There are no ClassLoader references stored in the ValidationExceptions
(VE) and I doublechecked serialization - all ValidationExceptions are
identical. The VE class only exists in one jar which is deployed in
several wars.
INFO [...] - Not a ValidationException:
[...].validation.ValidationException
INFO [...] - thrown Exception class:
[...].validation.ValidationException:
[...@[...].validation.validationexception@f8f...@cid:178a...@]
:
[...@org.apache.catalina.loader.webappclassloader@294...@cid:1d38...@]
INFO [...] - expected Exception class:
[...].validation.ValidationException:
[...@[...].validation.validationexception@6dc...@cid:113e...@]
:
[...@org.apache.catalina.loader.webappclassloader@12b3...@cid:1d38...@]
Thread
ClassLoader:[...@org.apache.catalina.loader.webappclassloader@294...@cid:1d
38...@]
Hint: [...@fullyqualifiedclassname@instanc...@classid@]
As I already indicated in a previous mail I am currently debugging
jbossall-client code. At a first glance it seems to make use of
Thread.currentThread().getContextClassLoader() but I will have a closer
look.
Regards
Fares
-----Original Message-----
From: ext Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, March 25, 2010 8:48 PM
To: Tomcat Users List
Subject: Re: UndeclaredThrowableException as a result of false
ClassLoading
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fares,
On 3/25/2010 6:56 AM, Mikasch, Fares (EXT-IBM - DE/Berlin) wrote:
> In the case where the ValidationException is wrapped by the
> UndeclaredThrowableException, the WebappClassLoader instance of the
> current thread and the instance of the WebappClassLoader of the caught
> (and wrapped) ValidationException are different.
Can you supply the full source of ValidationException? Are you storing
ClassLoader objects in the ValidationException or anything like that,
which might have a problem being de-serialized? Is it possible that you
are throwing a ValidationException from one container whose
serialVersionID doesn't match that of the receiving container?
> getUniqueID also prints the ClassLoader information. In this case both
> ValidationExceptions are loaded by different WebappClassLoader
> instances.
Care to show us the output of the above code?
> It seems that during unmarshalling of the ValidationException it is
not
> predictable which ValidationException (identified by its ClassLoader)
is
> constructed. It seems that the WebApp may get a ValidationException
that
> doesn't fit to its own ClassLoader but to a ClassLoader of another
> WebApp.
Are you calling a lookback RMI server (meaning the JVM is contacting
itself)? It would be strange for one webapp to get an object that was
loaded by another webapp unless you had put your library in a shared
location or otherwise used some kind of shared resource: anything loaded
through RMI should probably come through the WebappClassLoader.
You might want to check to see if the RMI client always uses Thread's
"context class loader" to load/define new classes. Otherwise, you might
see some weirdness like this.
> Is this a bug of the tomcat? I mean shouldn't the WebApp get the
> ValidationException from the same ClassLoader that belongs to the
WebApp
> that invoked the RMI call?
One would hope, but this has absolutely nothing to do with Tomcat: RMI
is entirely outside Tomcat's scope.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkurvggACgkQ9CaO5/Lv0PC2awCgsEOJoamv1fh5zVQy0Avhdpmo
4fQAnjF93rzRyCAObMDoW/C/9KyUcfGu
=mvkF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
