Welcome to

Currently I am involved in a project that is moving away from a proprietary workflow solution to a JBPM based workflow solution. One of the first things I attempted to do was try and make jBPM integrate with the identity management solution used in the project. I knew that jBPM comes packaged with some sort of identity component so I started reading up on it in the userguide.

“Management of users, groups and permissions is commonly known as identity management. jBPM includes an optional identity component that can be easily replaced by a company’s own identity data store.”

Sounds good. But then I kept on reading

When you want to use your own datasource for organisational information such as your company’s user database or ldap system, you can just rip out the jBPM identity component. The only thing you need to do is make sure that you delete the line …
<mapping resource="org/jbpm/identity/User.hbm.xml"/>
<mapping resource="org/jbpm/identity/Group.hbm.xml"/>
<mapping resource="org/jbpm/identity/Membership.hbm.xml"/>
from the hibernate.cfg.xml
The ExpressionAssignmentHandler is dependent on the identity component so you will not be able to use it as is. In case you want to reuse the ExpressionAssignmentHandler and bind it to your user data store, you can extend from the ExpressionAssignmentHandler and override the method getExpressionSession.
protected ExpressionSession getExpressionSession(AssignmentContext assignmentContext);

Yikes! What more, the reference to ExpressionAssignmentHandler class is actually hardcoded. So you cannot use a class that simply extends from ExpressionAssignmentHandler. It looks like you have to physically break open the jbpm-identity jar and replace the ExpressionAssignmentHandler contained within by a modified version

This must be some new kind of easy

update: Someone already submitted a Jira issue for this

Many java methods, such as Thread.sleep and Process.waitFor can throw an Interruptedexception. InterruptedException is a checked exception and as such requires you to explicitly catch it. Up until recently I’ve always simply swallowed this exception. I was fairly confident that this was the proper way to deal with this exception because this is how I’d seen others handle it many times over. As it turns out I was wrong and this is the worst possible way to handle an interrupted exception

Brian Goetz of java concurrency in practice fame has written an article on the subject that is definitely worth a read

If there is anything you should take away from reading this article it is this :

“At the very least, whenever you catch InterruptedException and don’t rethrow it, reinterrupt the current thread before returning.”

Its interesting to see that even the spring guys initially got this wrong It was fixed in spring 1.2.8