My first question would be - do we really need to close ProcessEngine upon console undeployment? I can think of few cases where such approach could be dangerous - just because console was down (either by administrator or server failure) whole process engine will be stopped. Is this desired?
In my opinion console shall be treated as optional (non intrusive) component so removing it shall not affect the process engine.
Does it affect only Tomcat?
The process engine needs to be closed by the module that created it. In JBoss AS this is already covered since jBPM is deployed as a service. The JbpmService bean correctly closes the engine on stop.
In Tomcat the situation is more complicated. Because it lacks the notion of services, the jbpm-console app creates the process engine itself. The engine cannot be managed by a separate module and shared via JNDI because Tomcat provides a read-only initial context.
In fact, the situation is aggravated due to Configuration.getProcessEngine() returning a shared instance. I take this method to be a formal equivalent of the HibernateUtil class in standalone environments. Unfortunately, it is tempting to call this method from within containers, where it is totally insane. The engine becomes reachable from the entire VM and there is no clear point at which it can be closed.
If it comes to probable solution, we could register listeners (ServletContectListeners) for console to close down process engine on application destroy.
This would be an option if the shared ProcessEngine could be closed on servlet context destruction, which is not possible as said before. If the servlet context listener built its own unshared engine on initialization, it could close it on destruction. Unfortunately such an engine is unreachable for the console integration components. In a typical web app it would be set as an attribute of the servlet context, but the servlet context itself is unreachable as well.
One promising alternative I want to investigate is the Tomcat custom resource factory. There is prior art in this direction involving the Hibernate session factory.