[
https://issues.apache.org/jira/browse/AXIS2-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487341
]
simishag commented on AXIS2-1596:
---------------------------------
I've narrowed down this behavior a bit. I'm using Tomcat 5.5, Axis2 1.1.1 and
simple POJOs.
Hot update works, sort of, if a method is added or removed from the service
class, in that it will correctly handle (or not handle) SOAP requests for the
method. If I add a method getFoo() that returns a String, I can query the REST
URL a few seconds after I upload my new AAR, without needing to restart
anything. I can then comment that method out and rebuild/deploy the AAR, and
then the REST URL correctly says "I cannot find a service." I can then restore
the method, comment it out, redeploy, etc., as many times as I want, and Axis
appears to reliably detect whether the method exists in the current AAR.
Hot update does not work if the body of a method is merely changed. Also,
trying to trick the hot update by removing and adding the method does not work
either. I did the above steps again, but this time I also updated the method
body when I restored the method, and I still get the old output. The only way
to get reliable "hot update" of the new AAR is to either restart Tomcat or
reload Axis2 from the Tomcat Manager.
My guess is that the Axis is smart enough to check the current AAR and classes
to see what methods the service supports, but that the original class is still
held in memory somewhere. Is this something to do with the Tomcat classloader?
> Re-Deployment is somewhat unreliable.
> -------------------------------------
>
> Key: AXIS2-1596
> URL: https://issues.apache.org/jira/browse/AXIS2-1596
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
> Affects Versions: 1.1
> Environment: Win XP SP2, Mozilla Firefox 1.5.0.7, Tomcat 5.5.20.
> Reporter: Rainer Menzner
> Assigned To: Deepal Jayasinghe
> Priority: Minor
>
> When recompiling a service and re-deploying the resulting archive, it can
> happen that the status of the tomcat / webservice is not exactly predictable.
> Alas, this effect is not reproducable. I encountered the following two
> situations:
> 1) After changing the function body of a webservice method, recompiling and
> re-deploying (at least the archive file has been copied!), the webservice
> method executed the previous code.
> 2) After renaming a function, the page
> http://localhost:8080/axis2/services/listServices showed both the former
> function at the new function.
> Restarting tomcat solves these problems. However, according to what is
> documented, one should rely on deployment by coyping the archive file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
