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
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
