[jboss-user] [jBPM] New message: "Re: Upgrade from JBPM3 to JBPM4 woes"

nick bauman do-not-reply at jboss.com
Wed Feb 3 17:20:50 EST 2010


User development,

A new message was posted in the thread "Upgrade from JBPM3 to JBPM4 woes":

http://community.jboss.org/message/524023#524023

Author  : nick bauman
Profile : http://community.jboss.org/people/nick.bauman

Message:
--------------------------------------------------------------
Thanks Ronald,
 
That's too bad. We're blazing a trail with what we can get compiling and passing tests, hoping your warnings aren't going to be showstoppers.
 
Well, we interact directly with the ProcessInstance on workflow start. We also have a couple of places where external timers work with processes in progress.
 
Specifically what we do in v3:
 
Node currentWaitState = pi.getRootToken().getNode();
 for (int i = 0; i < timedNodes.length; i++) {
   if (timedNodes[i].equals(currentWaitState.getName())) {
     // Can we get out of here?
     if (currentWaitState.hasLeavingTransition(TIME_OUT)) {
       pi.signal(TIME_OUT);
       return;
     }
    // Misconfigured process definition
     throw new RuntimeException("Workflow timed out on current state, but no corresponding timeout transition found.");
   }
 }
 log.debug("Workflow departed any timed state.");
 
Not sure how we sort that atm for v4. v3 was much more "hackable", and I mean that in a good way. The model was pretty small and coherent: the only thing that didn't make a lot of sense was why you have Node and State. Should be just State is a non-transient and Node is a transient state. IOW a boolean would have worked, my $0.02.
 
Spring integration: What worked well with us was making various adaptors for Spring DI into a process defintion where JbpmTemplate was less than perfect.
 


--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/524023#524023




More information about the jboss-user mailing list