Mark Egan [https://community.jboss.org/people/xmrk] created the discussion
"Exposing WorkItemHandler as an EJB (3.1) and referencing that work item handler from the BPMN process definition" To view the discussion, visit: https://community.jboss.org/message/747651#747651 -------------------------------------------------------------- JBPM 4.4 allowed us to expose an EJB and reference that <java> node within the JPDL using the attribute ejb-jndi-name ([per devguide: http://docs.jboss.com/jbpm/v4/devguide/html_single/#java http://docs.jboss.com/jbpm/v4/devguide/html_single/#java]). This was remarkable as it allowed deploying new, heavy Activities without the need of cracking open the process engine component itself. +Does jBPM 5.x have any similar capabilities?+ The following two options would allow a similar pattern. I have made an attempt to avoid Spring injection as I haven't found a need for it given the current capabilities of EJB 3.1 / CDI: ----- #1: Implement a configuration @Singleton internal to the process engine component that exposes the following: {code}public void addWorkItemHandler(String id, WorkItemHandler workItem); public void removeWorkItemHandler(String id);{code} and delegates the following: {code}private Map<String, WorkItemHandlers> workItemHandlers;{code} Implement an external @Singleton EJB that provides a WorkItemHandler. That WorkItemHandler is injected with configuration @Singleton and registers itself with that configuration during the @PostConstruct callback. I used singletons here to easy state consistency (or render it unnecessary). As such, it doesn't take advantage of pooling. There may be ways to do something similar with other EJB 3.1 / CDI technologies - I haven't explored some of the other options. ----- #2: Implement a proxy WorkItemHandler internal to the process engine component that is provided a JNDI name within the parameters Map. That WorkItemHandler would perform a lookup on the JNDI name and call executeWorkItem on the resolved resource by forwarding the original workItem and manager. This would allow container managed pooling. ----- I originally implemented #1 when I jumped into this issue only to think of #2 later. I'll likely be refactoring to the #2 pattern if no one has a better option for me. My hope is that jBPM 5.x already provides a community vetted and exercised solution rather than having to implement my own. Thanks, -mark -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/747651#747651] Start a new discussion in jBPM at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2034]
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
