-
1. Re: Invalid usage of undeployed classloader...
cinaed Apr 25, 2008 11:15 AM (in response to cinaed)If I stop the server, clean up the work and tmp directories and then start the server again I'll get rid of the problem (for a while - until it shows up again).
-
2. Re: Invalid usage of undeployed classloader...
kconner Apr 25, 2008 11:26 AM (in response to cinaed)Did the service shutdown cleanly from the previous deployment? Any errors in the log?
Also, can you describe what this service is doing and let us know which version of the ESB you are using? -
3. Re: Invalid usage of undeployed classloader...
cinaed Apr 26, 2008 8:06 AM (in response to cinaed)Hi,
Cannot see anything strange in the logs when redepolying so
from this point of view the redeploy looks ok.
I'm using the ESB "JBESB_4_2_1_GA_CP1" version.
The service has two structural blocks of which one part consist of actions
executing in the process phase doing some transformations (informat->xml,
xml->pojo and pojo->outFormat), payloadlocation activities, schemavalidation
etc and one part consiting of actions executing in the outcome phase
(processSuccess and processException) where the message is prepared for file
transfer, email feedback etc. and finally the payload is delivered by ftp
and a feedback message is sent by email (both ftp and email is handled by
the existing notifiers (NotifyFTP and NotifyEmail).
The exception can happen in any action but so far (and as far as I remember)
only in the outcome phase.
Some of the actions used in the flow are packaged in my own esb-archive and
some are packaged in 3:rd party archives or own gen/common-like esb-archives.
Also have some inheritance to classes in jboss archives and own gen/common-
like esb-archives. -
4. Re: Invalid usage of undeployed classloader...
kconner Apr 28, 2008 5:17 AM (in response to cinaed)There are two possibilities that I am aware of.
The first is that the listener was unable to cleanly bring down the executor and, if so, you should see the following message, 'Tasks remain active in executor'.
The second is that the action class has a reference to an object from a classloader that has been undeployed. If this is the case then the code reference by the following may shed some light on the matter.at ownNamespace.OwnActionClass.ownMethod(OwnActionClass.java:94)
Is this something that you can provide a simple test case for?