User development,
A new message was posted in the thread "Upgrade from JBPM3 to JBPM4 woes":
http://community.jboss.org/message/524033#524033
Author : Ronald van Kuijk
Profile :
http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
Nick,
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.
processInstance.signal()
becomes
executionService.signal(processInstance);
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?
Cheers,
Ronald
--------------------------------------------------------------
To reply to this message visit the message page:
http://community.jboss.org/message/524033#524033