"kukeltje" wrote : | That is not what I meant, I meant looking at the droolsflow editor to see how the extensibility is done there. I pretty confident an example in drools would work (I tested one myself here ;-)) | I really did some SOA today, it looks like it leaves me a bit of braindead .... which is at least better than the first translation of this term. Looking at the DroolsFlow editor is a good idea .... I hope that I don't repeat things you already knew, but my first impression of the architecture involving workItems is the following: DroolsFlow divides the definition of workItems in some sort of MVC concept .... At first there is a MVEL-Definition in your META-INF folder which describes how to represent a node type in the editor and it's abstract parameters and properties. And secondly there is a additional Representation of a WorkItem at runtime with a WorkItemHandler. Such a handler is itself a class implementing the WorkItem-Interface with a central executeWorkItem method containing your domain specific code. WorkItemHandlers are normal java objects which are intanciated by the developer and passed to a WorkItemManager at runtime. Those handlers are then notified when a process instance signals a workItem node. "kukeltje" wrote : | Maybe a solution where the designer could pick up classes in the project and runtime adapt the pallet to those classes that are just within this project. Then just adding a jar to your project would be sufficient. | Yes adding such an option to the GPD could be a solution .... or did I miss the point again :-/ . "barteljan" wrote : | I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations .... | "kukeltje" wrote : | hmmm.... where do you leave this config file then... I think it is more cumbersome than to just add a jar to your project. | Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future. In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better .... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254491#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...