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

Ronald van Kuijk do-not-reply at jboss.com
Wed Feb 3 18:13:12 EST 2010

User development,

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


Author  : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje

> Not sure how we sort that atm for v4. 
Your example should still be possible. use e.g. the  getActiveActivities on the execution service to get 'nodenames'. Getting the transition of all kinds of 'nodes' is going to be an addition in 4.4. afaik.
> v3 was much more "hackable",
> and I mean that in a good way.
4 stil is, You can often cast to *Impl classes and do more. The major difference is that there is an official 'stable' public api and you should use services to interact with the engine, not the model itself
So e.g.
> The model was pretty small and coherent:
Sure? Others think differently... I agree that once you were into it it was usable. But I've seen many do it wrongly.
> the only thing that didn't make a lot of sense was why you have Node and State.
This one is clear... Node had no default behaviour... just like custom in jBPM 4. State  was just a state, like in jBPM 4
> Should be just State is a non-transient and Node is a transient state. IOW a boolean would have worked, my $0.02.
Yes but that was because you could add 'custom behaviour' to state to. Should not have been so, then the difference would have been much more clear.
> Spring
> integration: What worked well with us was making various adaptors for
> Spring DI into a process defintion where JbpmTemplate was less than
> perfect.
Anything less then perfect (ok, exaggerated a little) should not be used or fixed. Nobody ever did fix the template.... why? Not used a lot? Scared? .... If I may ask why didn't you?


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

More information about the jboss-user mailing list