Hi Chris, Apparently I mixed up some lines regarding the traces during copy and paste. So here comes the correct trace:
INFO [...] - Thread ClassLoader: [...@org.apache.catalina.loader.webappclassloader@785...@cid:1d38...@] INFO [...] - BusinessDelegate ClassLoader: [...@org.apache.catalina.loader.webappclassloader@785...@cid:1d38...@] INFO [...] - expected Exception class classloader: [...@org.apache.catalina.loader.webappclassloader@785...@cid:1d38...@] INFO [...] - thrown Exception class classloader: [...@org.apache.catalina.loader.webappclassloader@12b3...@cid:1d38...@] INFO [...] - Wrapped exception Class: [...@[...].validation.validationexception@ada...@cid:1176...@] INFO [...] - Wrapped exception ClassLoader......: [...@org.apache.catalina.loader.webappclassloader@12b3...@cid:1d38...@] - parent: [...@org.apache.catalina.loader.standardclassloader@10f0...@cid:1c86...@] INFO [...] - Not a ValidationException: [...].validation.ValidationException INFO [...] - thrown Exception class: class [...].validation.ValidationException: [...@[...].validation.validationexception@ada...@cid:1176...@] INFO [...] - expected Exception class: class [...].validation.ValidationException: [...@[...].validation.validationexception@11f2...@cid:12ca...@] Sorry for the inconvenience. So now you can see here that both ValidationExceptions although of the same fully qualified name have a different class id because they are loaded by different class loaders. The expected ValidationException has the same ClassLoader as the current thread's context class loader and the business delegate which was called to do the RMI call. 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
