date:20100326

RE: UndeclaredThrowableException as a result of false ClassLoading

2010-03-26 Thread Mikasch, Fares (EXT-IBM - DE/Berlin)

Hi Chuck,

Thanks for your response.

You are right, the webapp does the RMI call, and as I am debugging I got
unsure if this is a tomcat issue or a jbossall-client(.jar) issue.

Of course it is the Java runtime that wraps exceptions with the UTE when
the (non Runtime-) Exception does not meet the interface.

To reproduce this issue I didn't use the SOAP service. 

Some additional information: Sometimes the behavior changes during the
runtime of the tomcat from wrapped to unwrapped and vice versa. But it
is much easier to reproduce it by just restarting the tomcat a few times
and retry.

Regards
Fares

-Original Message-
From: ext Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: Thursday, March 25, 2010 4:16 PM
To: Tomcat Users List
Subject: RE: UndeclaredThrowableException as a result of false
ClassLoading

 From: Mikasch, Fares (EXT-IBM - DE/Berlin)
 [mailto:fares.mikasch@nsn.com]
 Subject: UndeclaredThrowableException as a result of false
ClassLoading
 
 Short description of the use case:
 - User fills form with some wrong information
 - tomcat sends (RMI call) to another server

Let's get the terminology right: it's your webapp doing this, not
Tomcat.  Tomcat has no knowledge of or involvement with outbound
connections that your webapp attempts.

 - tomcat _sometimes_ wraps the ValidationException with
 UndeclaredThrowableException

No, Tomcat doesn't.  There is no usage of UndeclaredThrowableException
within Tomcat.

 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.

Are you sure they are instances of *Tomcat's* WebappClassLoader?  Note
that Axis uses its own classloading mechanism, and you may well be
stumbling into a problem with that.

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


-
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

RE: UndeclaredThrowableException as a result of false ClassLoading

2010-03-26 Thread Mikasch, Fares (EXT-IBM - DE/Berlin)

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

RE: UndeclaredThrowableException as a result of false ClassLoading

2010-03-26 Thread Mikasch, Fares (EXT-IBM - DE/Berlin)

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

Shutdown hook for correctly unloading drivers

2010-03-26 Thread Timo Meinen

Hi,

I would like to know, if there is a shutdown-hook for Tomcat
available. Or what the prefered way is, to correctly unload drivers
like JDBC drivers.

Unloading the drivers seems to be important for us, because after
redeploying the web appliction to often during continuous integration
leads to a OutOfMemory-Errors. And although Tomcat tells me, that it
forces the driver to unload, I can see a significant amount of memory
allocated additionally each time the webapp is redeployed.

My webapp causes Tomcat at shutdown to throw these warning messages:

26.03.2010 12:49:38 org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc
SCHWERWIEGEND: A web application registered the JBDC driver
[com.mysql.jdbc.Driver] but failed to unregister it when the web
application was stopped. To prevent a memory leak, the JDBC Driver has
been forcibly unregistered.
26.03.2010 12:49:38 org.apache.catalina.loader.WebappClassLoader
clearReferencesStopTimerThread
SCHWERWIEGEND: A web application appears to have started a TimerThread
named [Timer-0] via the java.util.Timer API but has failed to stop it.
To prevent a memory leak, the timer (and hence the associated thread)
has been forcibly cancelled.
26.03.2010 12:49:38 org.apache.catalina.loader.WebappClassLoader
clearReferencesStopTimerThread
SCHWERWIEGEND: A web application appears to have started a TimerThread
named [MySQL Statement Cancellation Timer] via the java.util.Timer API
but has failed to stop it. To prevent a memory leak, the timer (and
hence the associated thread) has been forcibly cancelled.
26.03.2010 12:49:38 org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SCHWERWIEGEND: A web application appears to have started a thread
named [MultiThreadedHttpConnectionManager cleanup] but has failed to
stop it. This is very likely to create a memory leak.
26.03.2010 12:49:38 org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SCHWERWIEGEND: A web application created a ThreadLocal with key of
type
[org.aspectj.runtime.internal.cflowstack.ThreadStackFactoryImpl.ThreadCounterImpl]
(value
[org.aspectj.runtime.internal.cflowstack.threadstackfactoryimpl$threadcounteri...@4ebfa97b])
and a value of type
[org.aspectj.runtime.internal.cflowstack.ThreadStackFactoryImpl.ThreadCounterImpl.Counter]
(value
[org.aspectj.runtime.internal.cflowstack.threadstackfactoryimpl$threadcounterimpl$coun...@90ff2a1])
but failed to remove it when the web application was stopped. To
prevent a memory leak, the ThreadLocal has been forcibly removed.

55 matches

Mail list logo