topic Re: Deploying delegate classes in Alfresco Archive

Deploying delegate classes

tombaeyens — Fri, 18 Feb 2011 05:41:48 GMT

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 i

Re: Deploying delegate classes

bernd_ruecker — Fri, 18 Feb 2011 06:33:57 GMT

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.

Re: Deploying delegate classes

jbarrez — Fri, 18 Feb 2011 09:45:51 GMT

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.

Re: Deploying delegate classes

bernd_ruecker — Fri, 18 Feb 2011 10:25:37 GMT

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….

Re: Deploying delegate classes

tombaeyens — Fri, 18 Feb 2011 13:20:39 GMT

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.

Re: Deploying delegate classes

tombaeyens — Fri, 18 Feb 2011 13:21:27 GMT

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

Re: Deploying delegate classes

bernd_ruecker — Fri, 18 Feb 2011 15:43:38 GMT

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.

Re: Deploying delegate classes

mproch — Fri, 18 Feb 2011 16:06:12 GMT

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)

Re: Deploying delegate classes

tombaeyens — Fri, 18 Feb 2011 19:19:25 GMT

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?