This undeploy mechanism is the result of fixing RiftSaw-238 issue.
Before this patch, the undeployment mechanism is very simple as following.
When you undeploy a process, if this process status is 'Active', it will remove the associated endpoints.
otherwise, it won't remove them. So it will have following two issues.
1. If a process is 'Retired', even though you remove this process, the associated endpoints would not get removed.
2. If a process is 'Active', and it has a previous version, which should be in the 'Retired' status. Then those 'Retired' process won't work as it should be, because the associated endpoints gets removed in the undeployment procedure. (This is what RiftSaw-238 about).
At first, I was trying to add a flag on the undeployment logic, say if it has any previous retired processes, we won't deactivate the endpoints. otherwise, remove the endpoints. One problem is that the endpoint changes between version, like the wsdlLocation is changed in the generated JAX-WS classes.
So in the end, the solution to this problem is:
On the undeployment, it will remove the associated endpoints of the process. And then it will try to get the previous version of the process, if it found one, will activate that process, and then set it to 'Retried', by activating it first, this actually is to start all the needed endpoints for the process.
By using above solution, it will fix the above two issues that we had.
So just for clarification - if a previous process definition exists, even if in 'retired' state, but with no active process instances remaining, the endpoint will still be published again?
If this is correct, then I don't see this as being a problem. The BPEL process is still effectively available all the time it is deployed to the server, regardless of whether the BPEL process definition is in a retired state and therefore unable to accept new process instances. This is a BPEL process engine consideration, not one for the web service endpoint, so having the web service available all the time seems sensible.