[jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2742) Provide an API to access the WorkItem interface outside executeWorkItem()

Provide an API to access the WorkItem interface outside executeWorkItem() ------------------------------------------------------------------------- Key: JBRULES-2742 URL: https://jira.jboss.org/browse/JBRULES-2742 Project: Drools Issue Type: Feature Request Security Level: Public(Everyone can see) Components: drools-api, drools-core, drools-core (flow) Affects Versions: 5.0.0.FINAL, 5.0.1.FINAL, 5.1.0.FINAL, 5.1.1.FINAL Environment: Any Reporter: Julien Serdaru Assignee: Kris Verlaenen I had a discussion with Kris about this issue, please find below excerpts of our talks: Julien: When executing workItems synchronously, executeWorkItem() provides access to the WorkItem interface, and with it all the parameters that allow me to complete this task using completeWorkItem(). That is fine and works great. However, when the user decides to complete the task asynchronously (delegating persistence to Drools, whether JPA or memory), there is no way to access the workItem variables before calling completeWorkItem(). Right now I store the workItem variables in my own persisted entity when executeWorkItem() is called. It works, but it just seemed unnatural to duplicate variables that are already stored by Drools, especially when Drools is running on the same platform as the application completing the tasks. In my use case (but I could think of many others), I use Drools in a web container and have a WebTaskHandler workitem implementation configured using workItem parameters. It could be whether a web form is disabled of not, or a list of properties to validate...any variables that I need in order to be able to complete the task. Kris: As long as you understand what I was getting at when I was saying you should be aware you are actually querying our internal data, I do understand that, if you also know that you are actually duplicating information, I understand that you might simply want to reuse that. I don't mind exposing a method like that, although I would prefer it then to be part of an internal api as we call it, as we don't really want this type of functionality being used by most users. Taking a look at the implementation, it seems that the JPAWorkItemManager already has a public WorkItem getWorkItem(id) method. Though it currently is pretty difficult to get your hands on this implementation objects directly, but if I add it to the internal WorkItemManager interface, it should be trivial to access if you cast to that interface. Feel free to open up a JIRA and send me the link and I'll try to take a look at this.