topic To: jbarrez or tombaeyens, why build ProcessEngine this way? in Alfresco Archive

To: jbarrez or tombaeyens, why build ProcessEngine this way?

ccappuccino — Mon, 07 Jun 2010 10:41:57 GMT

Hi Guys, In alpha1, I see that we build a ProcessEngine by Configuration Configuration().configurationUrl(resource).buildProcessEngine()‍; it's flexible relatively. But in alpha2, I see we have modified the building-approach: we build the ProcessEngine through a DbProcessEngineBuilder (a

Re: To: jbarrez or tombaeyens, why build ProcessEngine this way?

joshuap — Mon, 07 Jun 2010 12:54:17 GMT

Hi
Guys,
In alpha1, I see that we build a ProcessEngine by Configuration
Configuration().configurationUrl(resource).buildProcessEngine(); it's flexible relatively.
But in alpha2, I see we have modified the building-approach: we build the ProcessEngine through a DbProcessEngineBuilder (and a ProcessEngineConfiguration).
But in that, there are some hardcodes I think, i.e. we construct the BpmnDeploy class directly in DeployManager class.
Why we do this modified? Is this a compromise or a permanent modify?
Why we don't parse these files "activiti.cfg.default.deployer.manager.xml….." to construct the ProcessEngine?

I only worked with Alpha 2, but on the Pojo thread, I also mention that I would love a way to configure a engine that doesn't tie me to a SQL database.

Re: To: jbarrez or tombaeyens, why build ProcessEngine this way?

tombaeyens — Wed, 09 Jun 2010 08:47:56 GMT

First, to work on the PVM only, you don't need a configuration.

Second, if you want to work with BPMN and persistence, then we only provide DB support for now. That's why it is called DbProcessEngineBuilder.

Joshua, if you say you don't want to be tied to a DB, are you referring to the cloud persistence? Atm, we envisioned a CloudProcessEngineBuilder for that. After we worked this out concrete (only in research atm) then we can check if it's possible to merge the two.

The configuration was changed to better facilitate wiring configuration completely in frameworks like spring. Now there is a ProcessEngineConfiguration. That is now completely specifyable in e.g. Spring's bean-xml (or any other IOC framework). So in that case you wouldn't need an activiti configuration file any more. The spring configuration would probably use the ProcessEngineConfiguration class directly, rather then the DbProcessEngineBuilder.

The DbProcessEngineBuilder is a convenience class that creates a ProcessEngineConfiguration and then a ProcessEngine based on a few simple properties. But a lot more is configurable. To have the fine level configuration options, you would need to use the ProcessEngineConfiguration.

The DbProcessEngineBuilder will cover all the environments and configurations for which we will have our QA set up in continuous integration. So if you stick within the DbProcessEngineBuilder, then you're sure that we have it covered in our QA lab (well… setting up the QA lab is still TODO, but i'm showing the plan we have)

Re: To: jbarrez or tombaeyens, why build ProcessEngine this way?

activiti-admin — Wed, 09 Jun 2010 11:46:02 GMT

The configuration was changed to better facilitate wiring configuration completely in frameworks like spring. Now there is a ProcessEngineConfiguration. That is now completely specifyable in e.g. Spring's bean-xml (or any other IOC framework). So in that case you wouldn't need an activiti configuration file any more. The spring configuration would probably use the ProcessEngineConfiguration class directly, rather then the DbProcessEngineBuilder.

Oh Yes.
Great, we expect Activiti progressing by and by.