JBossDeveloper

Hello Joram,

I will try to provide the stacktrace tomorrow.

The situation is the following. I've got a process definition with a couple of automated activities, a bunch of java classes mainly used to invoke Axis2 webservices and 2 tasks for users. The process definition is deployed with no problem. I have a webservice using the jBPM api to start a process instance.

When the Tomcat server is freshly started and there is no process engine instance yet I call the webservice which tries to retrieve the process engine which is then created and stored. But the starting of the process fails and the exception telling that JpdlProcessDefinition cannot be cast to java.util.List is thrown.

If I use the jBPM console afterwards to start a process instance this error does not show up but a different one since I cannot supply the process instance variables needed in the first and automated activity via the jbpm-console. Strangely afterwards I can start as many process instances as I want with using my webservice without problems and they all run without problem from start to end.

I had trouble seeing more than the cast exception but as bwestrich stated there is normally an inner cause for this one but I could not locate one.

I'll try to get the stacktrace. Is there something you shouldn't do within java classes invoked by activities in the process? For example regarding calls in the constructor or whatever?

Thanks for any hints
Sebastian

Forgot to mention that if I use a different process definition to be started like this it works fine. So it must be something with the definition or the implementation classes??

The error usually meant that there was something wrong with the process xml - but I've never seen it being thrown at runtime.

Regarding java activities, there are no limitations for the constructor (as long it is the default constructor).

It sure sounds like a strange problem. i'm curious to see what the cause is ;-)

This is the only error I see:

INFO: exception while executing command org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd@5ad89e02
java.lang.ClassCastException: org.jbpm.jpdl.internal.model.JpdlProcessDefinition cannot be cast to java.util.List
 at org.jbpm.pvm.internal.repository.ProcessDeployer.deploy(ProcessDeployer.java:64)
 at org.jbpm.pvm.internal.repository.DeployerManager.deploy(DeployerManager.java:46)
 at org.jbpm.pvm.internal.repository.RepositorySessionImpl.getObject(RepositorySessionImpl.java:120)
 at org.jbpm.pvm.internal.query.ProcessDefinitionQueryImpl.execute(ProcessDefinitionQueryImpl.java:72)
 at org.jbpm.pvm.internal.query.AbstractQuery.untypedList(AbstractQuery.java:65)
 at org.jbpm.pvm.internal.query.AbstractQuery.untypedUniqueResult(AbstractQuery.java:69)
 at org.jbpm.pvm.internal.query.ProcessDefinitionQueryImpl.uniqueResult(ProcessDefinitionQueryImpl.java:145)
 at org.jbpm.pvm.internal.repository.RepositorySessionImpl.findProcessDefinitionByKey(RepositorySessionImpl.java:144)
 at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:58)
 at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:38)
 at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
 at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
 at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:46)
 at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
 at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceByKey(ExecutionServiceImpl.java:70)

So if I see it correctly, the error happens when starting a new process instance, the process definition isn't found in the repositorycache, which actually triggers the deployment again.

So far this is acceptable. Could you post your process?

I think this is hardly possible since it is splattered all over with implementation details. I'll have to check back after consultation. Maybe instead of posting I could supply it to you by e-mail.

I already raised log levels. Is there no way to see more?

Normally, the real cause should be shown somewhere down in the stacktrace (but as you stated, this is missing)?

Have you tried the process against the 4.3 trunk?

I'm going to try this. Also see my e-mail, please.

Joram, when there are persisted running process instances shouldn't the process definitions used by the running instances be in the repository already even after a Tomcat restart?