Alejandro Guizar wrote:
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.
I agree if you deploy jbpm and console as stand alone process engine, but what in case when there is application (user webapp) using jbpm and console is only for administration purpose and does not need to be running all the time? Then in my opinion web app should be the owner of the process engine and not the console. This is what I meant in my previous post.
Alejandro Guizar wrote:
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.
I was thinking that it could be treated as configuration option (for example using JVM parameters) if ServletContext shall start and destroy process engine. In such case it won't be only Tomcat specific solution but could be used by any other J2EE application server.
It will be probably used when running jbpm embedded in web application, once the web app is deployed console will use already created process engine.
Alejandro Guizar wrote:
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.
This sounds really good. Looking forward to results of your investigation.