cancel
Showing results for 
Search instead for 
Did you mean: 

Custom Classes in Classpath of calling App or Explorer?

rangoo
Champ in-the-making
Champ in-the-making
We have an Application(Message Driven Bean) kicking off our workflows.  Since our workflows have Java tasks , we made sure all the custom classes are in classpath, by putting our custom jars  in activiti-explorer Lib. Obviously Explorer and our Application make use of the same Datasource.  Couple of things

1) When our App started kicking off workflows, It started throwing Exception : Coudn't instantiate Custom TaskListener classes, even though the classes are in classpath of the explorer.  We placed the custom classes inside our App and things are working fine.  so should we have custom classes in classpath of the calling App and Explorer?

2) Also looks like WorkFlow calling class(in our Application) thread seems to be live till the entire WorkFlow (instance) is complete and so any exceptions thrown in the WorkFlow are thrown back to the calling Class. Is this correct?

Let me know your inputs.

7 REPLIES 7

rangoo
Champ in-the-making
Champ in-the-making
NOTE: Application & Explorer use the same activiti configuration

frederikherema1
Star Contributor
Star Contributor
1) Your custom classes should be present on both the explorer and your app's class path. When you use the API in your class path, the process in run in that thread/app.

2) Yes, until a wait-state is reached (user-task, receive-task, …), a process-end or an async activity, the process is executed synchronously in the calling thread. Take a look at activiti:async in the user guide to have asynchronous continuation of parts of the workflow.

rangoo
Champ in-the-making
Champ in-the-making
Makes sense - As both need classes at various points(sync & async).

One question though - Consider a scenario where we upgrade the workflow( version increments) along with changes in the custom classes, But we still have Tasks in wait state( user-tasks/Java Tasks) looking for older version of custom classes. Since we upgraded the custom classes , these process instances may error out. What you think is the best way to handle this scenario?

trademak
Star Contributor
Star Contributor
The best way is to use other class names when moving to a new version.

Best regards,

rangoo
Champ in-the-making
Champ in-the-making
Yes, until a wait-state is reached (user-task, receive-task, …), a process-end or an async activity, the process is executed synchronously in the calling thread. Take a look at activiti:async in the user guide to have asynchronous continuation of parts of the workflow.

Ok, Now I have the custom classes only in Activiti-explorer(not in calling App) as I have a marked my callactivity as async and also first task of it - a Java service Task(also marked async).  Since it is async I expected the JavaTask to look for classes in Activiti-Explorer's classpath instead of the App's classpath. But looks like it is not as I am getting a class not found exception. 

so even if marked async the calling Apps thread is still used?

trademak
Star Contributor
Star Contributor
Is your App also using a job executor? Or did you disable the job executor?
Because when it's enabled async tasks will still get executed by your App.

Best regards,

rangoo
Champ in-the-making
Champ in-the-making
My job executor is enabled only on explorer. I was using optional packages to share jar files(class files) across explorer and App. I dropped them and instead started using a maven jar dependency. Async is working fine now.