Deploying delegate classes

[tombaeyens]

Here's a new way of how we could deploy delegate classes to the engine.  This would solve the problem that delegate classes have to be deployed to every webapp that runs the ProcessEngine.

We could provide a method repositoryService.deployLibrary(InputStream).  This methods would store that library in the DB.   The classes in these libs would then become available to all processes in the whole engine. 

During ProcessEngine boot time, and as libraries or processes are deployed, the engine could keep a configurable directory in sync with the deployed libraries.   That way normal file classloading could be applied.  Although this file based classloading should be optional as in some environments it is not allowed.  And this solution would also work in a clustered setup.

Thoughts?

[bernd_ruecker]

Quick feedback before I leave to the office: Having classes in the database still doesn't feel right for me.

For me personally the most interesting is, how we can handle that problem correctly in the Java EE/JBoss AS environment, but that I think involves some custom solution for that environment (Deployer, scoped EAR deployments, …). For e.g. OSGI I don't know what that evolves and if they can work with the sketched solution.

[jbarrez]

Initially, I had the same opinion as Bernd: i didnt see the value of the classes-in-the-db.
However, the request has been coming regularly now, and people seem to really like it. It is also very good for demo's. So my opinion has switched over timer.

For EE/OSGI environments I think indeed a custom solution could be developed. But those will always be tailored to the app server at that point. And that could very wel co-exist with the db approach.

[bernd_ruecker]

I agree at least for demos, there it is nice. But normally I always get the question: "And how did you really deploy the delegation classes? In the database?? Are you insane???" 😉

But okay, since it would be an additional feature I don't mind, even if I wouldn't prioritize it too high. But that's basically your decision, so….

[tombaeyens]

Quick feedback before I leave to the office: Having classes in the database still doesn't feel right for me.

For me personally the most interesting is, how we can handle that problem correctly in the Java EE/JBoss AS environment, but that I think involves some custom solution for that environment (Deployer, scoped EAR deployments, …). For e.g. OSGI I don't know what that evolves and if they can work with the sketched solution.

So this is the problem: Suppose a user wants to use our existing webapps as is.  And also he wants to use the engine in his own application.  Then how does he make sure that delegation classes are found in those 2 environments?   It is very error-prone to explain to developers that they have to deploy their classes to every process engine that might end up running their process. 

Note that the solution I'm talking about here is different from classes in the business archive and in the deployment.  In this case, the libs would be visible process engine wide.  And I also indicated that as a kind of 'cache', the libs could be serialized to a local folder and then loaded through a normal classloader.

A second problem we need to address is the spring configuration.  If a user has a webapp and uses spring and wants to use beans from that context.  Same thing here.  All the instantiated process engines need to be made aware of that spring context.

[tombaeyens]

Yes OSGi is probably different.  Hopefully we're able to work out a strategy that works on every environment.

[bernd_ruecker]

Suppose a user wants to use our existing webapps as is. And also he wants to use the engine in his own application. Then how does he make sure that delegation classes are found in those 2 environments?

That isn't solved by having the delegation classes in the Database. Normally you need third party libraries, or service interfaces or whatever as well. The delegation class is only the tip of an iceberg.

All the instantiated process engines need to be made aware of that spring context.

What if you have one spring app and a non spring app? That's why scoped classloading was invented in Java EE, it is not just unnecessary complex 😉 But okay, hey, if you want to have it for demos or simple environment (e.g. the simple vacation process) I don't care. I just don't see it as a best practice to deploy a "real" application like that.

[mproch]

I think Bernd is right - maintaining same process engine configuration, together with 3rd party jars for different deployments would become really difficult.

I think for webapps it's better solution to expose REST API from user application - it's not that hard, I wrote about it on user forum: http://forums.activiti.org/en/viewtopic.php?f=6&t=1141
(of course the problem remains if there are many application which want to share process engine…)

In OSGi environment we would just use OSGi services to share process engine between applications (at least on same server)

[tombaeyens]

I didn't see the alternative yet.

So a user wants to build a webapp and use the Activiti APIs.  And this user also wants to use Activiti Explorer and Activiti Rest interface.  This is a very common use case.  What are the things that a user should do in order to get this running?  Would this require an appserver?