How to Disable CommandBasedWSHumanTaskHandler in CommandDelegate

[tcharman]

Hi

I have written a different implementation of the human task, as I have a bunch of external systems to integrate.  The work item handler extends either side of the human task lifecycle.  This works fine when running locally.

But when I deploy to jBPM console server, things go awry because the CommandBasedWSHumanTaskHandler is registered with the session in the CommandDelegate.  In turn, CommandBasedWSHumanTaskHandler registers a listener for human task events, which fire when the human task completes, and restarts my workflow, even though I have not included the CommandBasedWSHumanTaskHandler in my workflow.

My task handler listens for the same events, but by the time my task handler is ready to restart the process, it is too late - CommandBasedWSHumanTaskHandler has already started it.

This is really not desirable, as it means the behaviour on the server is different than when running locally through Eclipse, and it means I cannot contribute any of my own task handlers that interact with the human task service.  I see no way to remove the CommandBasedWSHumanTaskHandler registration except by forking the code, which I want to avoid.

Anyone any ideas?

Thanks

Tim

[swiderski.maciej]

This is know limitation that was already addressed with this jira. So from version 5.4 (or snapshot of it) you can already register your own handlers. Does it cover your requirements?

HTH

[tcharman]

Thanks for pointing this out.  We're upgrading to 5.4.0.Beta1.  Any idea when 5.4.0 will be released?

[demkezo]

We've updated to 5.4.0.CR1 to address this issue. We now have a problem where the WorkItemManager cannot complete our Human task and continue the process. We debugged and found that the workItemByteArray is not being persisted in the DB as it previously was, hence causing an issue when it is being read by the workItemManager.

Can anyone help?

Thanks

Khetha