nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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

ccappuccino

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?

Find more posts tagged with

Comments

joshuap

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.

tombaeyens

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)

activiti-admin

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.