[kukeltje]

In gateways it is called from the execute. For the externalActivities it is or better will be called from the signal in the activity(experimenting with that locally). Have to do some refactoring/simplification of the leave. It is now to big a method for different types of nodes.

I think it will work eventually.

[kukeltje]

(ps you already might have noticed that in our own implementations, it is best to use the impl classes and not the interfaces)

I have recently and it is becoming a problem. The PVM is created with jPDL as a reference/base. BPMN is a little different in some cases. I've implemented several workarounds now but that does not feel good. An example:

While parsing the transitions and adding them to the activities, I'd like to set the defaultOutGoingTransition on the activity. I cannot do that, since the findActivity in the CompositeElementImpl returns an ActivityImpl but I need the ExclusiveGateway since that is the only one that has the getDefault() on it (which outgoing transition is the default is on the exclusive gateway, not the transition).

If this was possible the parsing of the outgoing transitions would be cleaner as it currently is.

Any chance that this can be changed? Or otherwise please enlighten me why this is not an option.

[tom.baeyens]

I could not offer a stable API for activity implementations if it would have to cover all the jPDL functionality. That's why jPDL sometimes casts to implementation classes. Ideally the ActivityBehaviour interfaces would expose all necessary functionality. But time to get all that figured out and stable was not there. So I opted to start with an ActivityBehaviour API that only covers the basics. That gives us more time to explore our options before we promote that to supported API (read cast in stone).

Same is true for parsing. We could offer a more limited API to build up the process model. But that is going to take more research to get it right.

I don't think it is a big problem if implementing a new language for now requires the use of our internal PVM classes. I focussed first on the client API and the typical user pluggability like EventListeners and automatic activities.

[kukeltje]

I could not offer a stable API for activity implementations if it would have to cover all the jPDL functionality. That's why jPDL sometimes casts to implementation classes.

Oh, I don't mind jPDL to cast to it's implementation classes

Ideally the ActivityBehaviour interfaces would expose all necessary functionality.

Hmmm... activityBehaviour... maybe that is what I was missing. I'll have a look.

But time to get all that figured out and stable was not there. So I opted to start with an ActivityBehaviour API that only covers the basics. That gives us more time to explore our options before we promote that to supported API (read cast in stone).

Ok. then I should use compositeElement.findActivity(sourceRef).getBehaviour() instead... Ok, makes sense. (if you know it ;-)

I don't think it is a big problem if implementing a new language for now requires the use of our internal PVM classes.

On the contrary. If they are good, use them. I thought of creating e.g. a 'SequenceFlow' that does nothing more than extend Transition, but I did not do it (yet)

[kukeltje]

"kukeltje" wrote:

Ideally the ActivityBehaviour interfaces would expose all necessary functionality.

Hmmm... activityBehaviour... maybe that is what I was missing. I'll have a look.

But time to get all that figured out and stable was not there. So I opted to start with an ActivityBehaviour API that only covers the basics. That gives us more time to explore our options before we promote that to supported API (read cast in stone).

Ok. then I should use compositeElement.findActivity(sourceRef).getBehaviour() instead... Ok, makes sense. (if you know it ;-)

Yep, that did the trick. Only downside is that this is done while parsing and some parsing tests now throw an additional error (they are still green though!) that there is no behaviour. True, since parsing failed and null was returned for the 'behaviour' I did a small hack in checking the jBPM exception for this specific error and rethrow it if it was something different.