-
1. Re: dual jbpm context
tbee Jan 6, 2009 7:14 AM (in response to tbee)2. Or do I have to configure hibernate to use hsqldb in memory mode?
-
2. Re: dual jbpm context
tbee Jan 6, 2009 8:00 AM (in response to tbee)1. Having two JbpmConfigurations runs into some dead ends.
When trying to parse a ProcessDefinition from String using the static parseXmlString, underwater JbpmConfiguration.getInstance() is called.
JbpmConfiguration.getInstance(String) line: 278
JbpmConfiguration.getInstance() line: 257
JbpmConfiguration$Configs.getObjectFactory() line: 425
JbpmConfiguration$Configs.getObject(String) line: 437
JbpmConfiguration$Configs.getString(String) line: 441
ProcessDefinition.createNewProcessDefinition() line: 97
JpdlXmlReader.readProcessDefinition() line: 138
ProcessDefinition.parseXmlString(String) line: 150
Since I do not have a jbpm.cfg.xml anymore, it will revert to the embedded one. That is not the idea with having two separate configurations... -
3. Re: dual jbpm context
tbee Jan 6, 2009 8:17 AM (in response to tbee)"tbeernot" wrote:
When trying to parse a ProcessDefinition from String using the static parseXmlString, underwater JbpmConfiguration.getInstance() is called.
The problem basically is with the static ProcessDefinition.createNewProcessDefinition; it accesses a static inner class Configs:
String resource = JbpmConfiguration.Configs.getString("resource.default.modules");
That will result in trying to get the factory, which will see if an instance is available via the depricated method:
JbpmContext jbpmContext = JbpmContext.getCurrentJbpmContext();
Which ends up in JbpmConfiguration.jbpmConfigurationsStacks (a ThreadLocal variable).
If no instance is available, it will generate the default one, thus accessing jbpm.cfg.xml.
The approach would then have to be to push the active configuration on the thread local stack before each call and pop it afterwards.
This does not feel right. -
4. Re: dual jbpm context
kukeltje Jan 6, 2009 4:45 PM (in response to tbee)huh? can't you use to different named context in one config? One pointing to a hibernate config with persistance and one without?
USe http://docs.jboss.org/jbpm/v3/javadoc/org/jbpm/JbpmConfiguration.html#createJbpmContext(java.lang.String) then -
5. Re: dual jbpm context
tbee Jan 7, 2009 1:21 AM (in response to tbee)"kukeltje" wrote:
huh? can't you use to different named context in one config? One pointing to a hibernate config with persistance and one without?
USe http://docs.jboss.org/jbpm/v3/javadoc/org/jbpm/JbpmConfiguration.html#createJbpmContext(java.lang.String) then
I'm using two configs files here, haven't tried this. How would that look? -
6. Re: dual jbpm context
kukeltje Jan 7, 2009 6:41 AM (in response to tbee)put 2 jbpm-context in one config file and put a name attribute on each them
-
7. Re: dual jbpm context
tbee Jan 9, 2009 7:58 AM (in response to tbee)"kukeltje" wrote:
put 2 jbpm-context in one config file and put a name attribute on each them
I dunno; what to do with lines like this:JbpmConfiguration.getInstance().createSchema();
It should be done like:JbpmConfiguration.getInstance().createJbpmContext("mem").createSchema();
But that is not possible.
I have the impression that the whole API is not fully worked out. Maybe I should wait for the 4.0 release... -
8. Re: dual jbpm context
tbee Jan 9, 2009 8:02 AM (in response to tbee)"tbeernot" wrote:
JbpmConfiguration.getInstance().createSchema();
Ah, oeps:JbpmConfiguration.getInstance().createSchema("mem");
-
9. Re: dual jbpm context
tbee Jan 9, 2009 9:43 AM (in response to tbee)Ah... I finally "get" it.
If I want long running workflows, I use the JbpmContext and go off and persist it. Then I need to hold the id in session.
If I only want to do stuff in memory, I cannot use the JbmpContext at all, notably not for "findLatestProcessDefinition", since there is no store. I have to recreate a ProcessDefinition from the XML definition each time and store the process definition instace in the session. -
10. Re: dual jbpm context
kukeltje Jan 10, 2009 10:45 AM (in response to tbee)That is another option.... I use the 'mem' option with an in-memory database and when starting the app, I deploy the process to there. I also remove process instances from the in-memory database when they end... works great
-
11. Re: dual jbpm context
tbee Jan 10, 2009 11:19 AM (in response to tbee)"kukeltje" wrote:
That is another option.... I use the 'mem' option with an in-memory database and when starting the app, I deploy the process to there. I also remove process instances from the in-memory database when they end... works great
Doesn't this cause cleanup issues? When sessions are terminated? Or better; when the user simply cancels thus you never know it is terminated?
And technically you do not have an "no-persistence" setup; you have two persisted configurations, but one DB happens to be in-memory. (I tried you setup with hybernate removed from the configuration, but that does not work).
I want all in-memory processes to be cleared when the session is destroyed (explicitely or due to time out). -
12. Re: dual jbpm context
kukeltje Jan 10, 2009 4:30 PM (in response to tbee)"tbeernot" wrote:
Doesn't this cause cleanup issues? When sessions are terminated? Or better; when the user simply cancels thus you never know it is terminated?
No, use an HttpSessionListener, declare it in the web.xml and implement the sessionDestroyed method. In the session you can keep the processInstanceId and use that to cancel/remove the process. When the use clicks cancel it is (to me) obviously easier...."tbeernot" wrote:
And technically you do not have an "no-persistence" setup; you have two persisted configurations, but one DB happens to be in-memory. (I tried you setup with hybernate removed from the configuration, but that does not work).
Correct... but what I do not get is what you mean by 'with hibernate removed'. I have hibernate in both configs."tbeernot" wrote:
I want all in-memory processes to be cleared when the session is destroyed (explicitely or due to time out).
See my first statement. You can also link it e.g. to seam conversation timeouts etc... -
13. Re: dual jbpm context
tbee Jan 11, 2009 1:20 AM (in response to tbee)"kukeltje" wrote:
No, use an HttpSessionListener, declare it in the web.xml and implement the sessionDestroyed method. In the session you can keep the processInstanceId and use that to cancel/remove the process. When the use clicks cancel it is (to me) obviously easier....
Ah, yes, the session listener; that was added after I got knee deep in the servlet API and I keep forgetting it exists. Dumm me."kukeltje" wrote:
Correct... but what I do not get is what you mean by 'with hibernate removed'. I have hibernate in both configs.
Well, in one of you previous posts you said this:"kukeltje" wrote:
One pointing to a hibernate config with persistance and one without?
"Without persistence", for me that means "no persistence" and not "in-memory db", so I took hibernate out of the one configurations. As said; that didn't work. ThenI reread that part on the XML vs objects vs DB and finally saw the light; you either have a backing store (and can base on workflows stored in there), or you don't.
So thanks again!
Tom -
14. Re: dual jbpm context
kukeltje Jan 11, 2009 5:35 AM (in response to tbee)Well, in one of you previous posts you said this:
One pointing to a hibernate config with persistance and one without?
"Without persistence", for me that means "no persistence" and not "in-memory db", so I took hibernate out of the one configurations. As said; that didn't work. ThenI reread that part on the XML vs objects vs DB and finally saw the light; you either have a backing store (and can base on workflows stored in there), or you don't.
That is what you get when non native english speakers start writing short statements. Persistence to me is 'surving restarts'