jBPM/Spring/jUnit

[pojomonkey]

I am working on a application using Spring and jBPM. I'm also using springmodules for jBPM.

The application works fine, but so far I have avoided trying to create jUnit tests for the code that interacts with jBPM. This is in part due to the asynchronous activity associated with that, which makes it difficult to write application level tests.

Now that I've got a better grasp on it all, I'm trying to extend test coverage to include the application process flow elements.

The jUnit tests are base on Spring's AbstractJpaTests, and when the process is started, it should invoke the start-task assigment handler, but I get a DelegationException. This doesn't happen when the application runs normally.

Having spent about a day searching, reading and debugging, I could do with some clues as to where to look next.

I'd very much appreciate your suggestions. Thanks.

[salaboy21]

If you got a DelegationException if because you don't have your "action" classes in your application(test unit) classpath.. take a look at that!

Let me know if you still have problems!

[pojomonkey]

I was getting a ClassCastException for the handler class, which is then translated into the DelegationException - I guess I should have mentioned that - so it doesn't seem to be a classpath issue.

[salaboy21]

If you have a ClassCastException you should check your stack trace. Or you can show us how it looks like with your ActionHandler Code...

[pojomonkey]

Handler code is:

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.jbpm.graph.def.ProcessDefinition;
import org.jbpm.graph.exe.ExecutionContext;
import org.jbpm.graph.exe.ProcessInstance;
import org.jbpm.taskmgmt.def.AssignmentHandler;
import org.jbpm.taskmgmt.exe.Assignable;



public class NewProcessHandler implements AssignmentHandler {
 private static final long serialVersionUID = 1L;

 private final Log log = LogFactory.getLog(NewProcessHandler.class);

 public void assign(final Assignable assignable, final ExecutionContext executionContext) throws Exception {
 final ProcessInstance pi = executionContext.getProcessInstance();
 final ProcessDefinition pd = executionContext.getProcessInstance().getProcessDefinition();
 log.info("New process started: " + pd + " version " + pd.getVersion() + " key:" + pi.getKey());
 // Starts process
 executionContext.leaveNode();
 }

The only bit of stack trace I have handy is this:

org.jbpm.graph.def.DelegationException: com.xxx.bus.process.handler.NewProcessHandler
at org.jbpm.taskmgmt.exe.TaskMgmtInstance.performAssignment(TaskMgmtInstance.java:216)
at org.jbpm.taskmgmt.exe.TaskInstance.assign(TaskInstance.java:204)
at org.jbpm.taskmgmt.exe.TaskMgmtInstance.createTaskInstance(TaskMgmtInstance.java:154)
at org.jbpm.taskmgmt.exe.TaskMgmtInstance.createStartTaskInstance(TaskMgmtInstance.java:285)
at com.xxx.bus.process.ProcessManagerImpl$2.doInJbpm(ProcessManagerImpl.java:174)
at org.springmodules.workflow.jbpm31.JbpmTemplate.execute(JbpmTemplate.java:92)
at com.xxx.bus.process.ProcessManagerImpl.startProcess(ProcessManagerImpl.java:150)

The actual ClassCastException is thrown in TaskMgmtInstance.performAssignmentDelegation():

AssignmentHandler assignmentHandler = (AssignmentHandler) assignmentDelegation.instantiate();

[salaboy21]

please post the jpdl XML code.. where you are adding this assignment handler..

[pojomonkey]

The XML for the start state is:

<start-state name="start-state">
 <task name="StartProcess">
 <assignment class="com.xxx.bus.process.handler.NewProcessHandler"></assignment>
 <controller></controller>
 </task>
 <transition to="next-state" name="transition"></transition>
 </start-state>

[kukeltje]

Assignment handlers do not work in the start task. What does the logging tell you (maybe turn up the log level)

And guys... better to make a unit test from the beginning that demonstrates the problem instead of separate code snippets...

[pojomonkey]

"kukeltje" wrote:
Assignment handlers do not work in the start task.

That is an interesting nugget of information - why would the start task not permit assignment? Guess I'll have to re-read the docs etc.

My question still stands though - why does it fail when I try to jUnit the code, but (apparently) doesn't fail when the same code is executed in the application?

"kukeltje" wrote:
What does the logging tell you (maybe turn up the log level)

I can't run the app up right now - in the middle of some changes going through. But I will check as soon as I can.

"kukeltje" wrote:
And guys... better to make a unit test from the beginning that demonstrates the problem instead of separate code snippets...

I would have, but trying to extract a 'unit test' from hundreds lines of an application wasn't really practical.

[pojomonkey]

"kukeltje" wrote:
Assignment handlers do not work in the start task. What does the logging tell you (maybe turn up the log level)

Interesting - this just from the log file:

16:02:24,285 INFO [process.handler.NewProcessHandler] New process started: ProcessDefinition(ProjectProcess) version 1 key:1

That says the assignment handler IS invoked on the start task, when I run the app.

[kukeltje]

the reason is simple, well, it was a few years back. There is a start node. Someone/thing starts the process, so if there is a task in the start node, that task was *assumed* to be for that person. If someone just starts the process, and the first task is for someone else, leave the start node empty.

This reasoning might not be that obvious, though it is valid. This might change in jBPM 4 however. The fact that it is invoked (how do ypou see that from this log btw...) does not mean the result is used.

I would have, but trying to extract a 'unit test' from hundreds lines of an application wasn't really practical.

You got the assignmenthandler, part of the processdefinition out of those hundreds of lines of code didn't you? Making a runnable unit test out of it is only 30 minutes extra work. And what is more important, it is much easier for *us*, the ones prroviding support to make sure we are nut hunting ghosts because people make typos when doing partial cutting/pasting etc.... And if it seems to be a real problem, it is easier for us to reproduce....... So... all things considered, it is better to do.

btw, why do you do a leave node in an assignment handler? That is realy wrong.

[pojomonkey]

"kukeltje" wrote:
The fact that it is invoked (how do ypou see that from this log btw...) does not mean the result is used.

The fact that the message is logged from the handler...

"kukeltje" wrote:
btw, why do you do a leave node in an assignment handler? That is realy wrong.

Hang-over from my early experiments with jBPM. I think without it, although the process starts, it gets 'stuck' in the start state.

Over the past 9 months my understanding of jBPM has improved a lot, and I'm begining to tackle the various issues (like that node exit) that are left over from early experiments - hence why I'm trying to get some jUnit tests going for the jBPM usage in the app.

All I was hoping for with this thread was to get some ideas as to why the DelegationException is thrown when I invoke createStartTaskInstance() from a jUnit test, but NOT when the same code is run as part of the normal running of the app.

I had assumed that the range of possible causes for that exception had probably been experienced by someone. I'm still hoping that someone will give me some guesses or suggestions for investigation.

[pojomonkey]

As it is, I've decided to simply remove the handler and the start-task and try move forward. I haven't got the time to waste - time pressures on the project won't allow for it.

[kukeltje]

"kukeltje" wrote:
The fact that it is invoked (how do ypou see that from this log btw...) does not mean the result is used.

The fact that the message is logged from the handler...

Yes, the handler is called, I see that. I meant that the 'result' isn't used.

"kukeltje" wrote:
btw, why do you do a leave node in an assignment handler? That is realy wrong.

Hang-over from my early experiments with jBPM. I think without it, although the process starts, it gets 'stuck' in the start state.

Still then, it is realy wrong. And if you have a start task don't you want it to stay in the start node???

All I was hoping for with this thread was to get some ideas as to why the DelegationException is thrown when I invoke createStartTaskInstance() from a jUnit test, but NOT when the same code is run as part of the normal running of the app.

That is new information (or maybe I missed it somewhere in the split posts). Most often it is a classloader issue if you see this different behaviour

I had assumed that the range of possible causes for that exception had probably been experienced by someone. I'm still hoping that someone will give me some guesses or suggestions for investigation.

That is why a real unittest is handy for *us* so we can try to replicate the issue locally...

[pojomonkey]

I agree that my original use of the assignment handler for the start-task etc. was flawed - hence why I've now removed it.

All I was hoping for with this thread was to get some ideas as to why the DelegationException is thrown when I invoke createStartTaskInstance() from a jUnit test, but NOT when the same code is run as part of the normal running of the app.

"kukeltje" wrote:
That is new information (or maybe I missed it somewhere in the split posts). Most often it is a classloader issue if you see this different behaviour

It was in my first post, but probably not obvious. Yes, it does seem to be a classloader issue - running in the context of JUnit - for now I'm getting:

java.lang.ClassCastException: org.springmodules.workflow.jbpm31.JbpmHandlerProxy
 at org.jbpm.graph.def.Action.execute(Action.java:121)

Following from:

getJbpmTemplate().execute(new JbpmCallback() {
 public Object doInJbpm(final JbpmContext context) {

 // Create a new process instance
 final ProcessInstance pi = context.newProcessInstanceForUpdate(processName);

 if (pi != null) {
 pi.getRootToken().signal();
 }

 return null;
 }
 });

As I've got a deadline looming, I have no choice but to give up on trying to solve this conundrum, for now.

Thanks for your input so far. If anyone has any similar experience trying to JUnit test their Spring app (with jBPM 'under the hood') then I'd be glad to hear how you got around this issue.