new configuration approach

[tombaeyens]

Hi Folks,

Yesterday I committed a new configuration approach based on David's input.  Here's an overview of my first attempt:

In the API, you can only use the builder to create a new process engine.  It can be configured programatically, with a properties resource or with a combination of both:

ProcessEngine processEngine = new DbProcessEngineBuilder()
        .configureFromPropertiesResource("activiti.properties")
        .buildProcessEngine();

ProcessEngine processEngine = new DbProcessEngineBuilder()
        .setDatabaseH2()
        .setJdbcUrl("jdbc:some:url")
        .buildProcessEngine();
‍‍‍‍‍‍‍‍‍

Method setDatabaseH2() also fills in default values for the other configuration properties.  Specific property setters will win from the defaults set by the setDatabaseXxx methods. Order doesn't matter.

ProcessEngines.init() will scan for all activiti.properties files on the classpath and create a process engine for each configuration file found.



In the implementation, a ProcessEngineConfiguration contains getters and setters for all configurable pieces in the engine:

public class ProcessEngineConfiguration {

  String processEngineName;
  DeployerManager deployerManager;
  VariableTypes variableTypes;
  ScriptingEngines scriptingEngines;
  JobExecutor jobExecutor;
  boolean jobExecutorAutoActivate;
  IdGenerator idGenerator;
  PersistenceSessionFactory persistenceSessionFactory;
  ProcessCache processCache;
  CommandContextFactory commandContextFactory;
  CommandExecutor commandExecutor;
  DbSchemaStrategy dbSchemaStrategy;
  ProcessServiceImpl processService;
  IdentityServiceImpl identityService;
  TaskServiceImpl taskService;
  ManagementServiceImpl managementService;

  public ProcessEngineConfiguration() {
    deployerManager = createDefaultDeployerManager();
    variableTypes = createDefaultVariableTypes();
    scriptingEngines = createDefaultScriptingEngines();
    jobExecutor = createDefaultJobExecutor();
    jobExecutorAutoActivate = createDefaultJobExecutorAutoActivate();
    idGenerator = createDefaultIdGenerator();
    persistenceSessionFactory = createDefaultPersistenceSessionFactory();
    processCache = createDefaultProcessCache();
    commandContextFactory = createDefaultCommandContextFactory();
    commandExecutor = createDefaultCmdExecutor();
    dbSchemaStrategy = createDefaultDbSchemaStrategy();
    processService = createDefaultProcessService();
    identityService = createDefaultIdentityService();
    taskService = createDefaultTaskService();
    managementService = createDefaultManagementService();
  }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

All those configurable pieces have defaults.
ProcessEngineConfiguration is not part of the public API.
The idea is that ProcessEngineConfiguration could be constructed with spring-bean-xml.
Then ProcessEngineConfiguration.buildProcessEngine() wires the configurable pieces together and produces the ProcessEngineImpl:

  public ProcessEngineImpl buildProcessEngine() {
    // wiring the configurable objects together
    this.processService.setCmdExecutor(commandExecutor);
    this.identityService.setCmdExecutor(commandExecutor);
    this.taskService.setCmdExecutor(commandExecutor);
    this.managementService.setCmdExecutor(commandExecutor);
    this.idGenerator.setCmdExecutor(commandExecutor);
    this.processCache.setDeployerManager(deployerManager);
    this.commandContextFactory.setDbidGenerator(idGenerator);
    this.commandContextFactory.setDeployerManager(deployerManager);
    this.commandContextFactory.setPersistenceSessionFactory(persistenceSessionFactory);
    this.commandContextFactory.setProcessCache(processCache);
    this.commandContextFactory.setScriptingEngines(scriptingEngines);
    this.commandContextFactory.setTypes(variableTypes);
    this.jobExecutor.setCmdExecutor(commandExecutor);
    this.persistenceSessionFactory.setDbidGenerator(idGenerator);
    this.commandExecutor.setProcessEngineConfiguration(this);

    return new ProcessEngineImpl(processEngineName,
                                 processService, 
                                 identityService, 
                                 taskService, 
                                 managementService,
                                 dbSchemaStrategy,
                                 jobExecutor,
                                 jobExecutorAutoActivate,
                                 persistenceSessionFactory);
  }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

There were some occurences left where we couldn't replace the static thread local lookups with injection as an alternative.  This is for all usages of configurable objects in the engine interpretation process.  As those runtime process instance domain objects should also be usable without persistence.

We could aim to go one step further and also add injection to runtime process instance objects.  But then we need to intercept all loads and perform injection of the CommandContext in all the persistent objects that are loaded from the db.

This explanation might be bit unclear.  But shoot your questions and then I know which part I should explain differently 😉

[jbarrez]

Nice work, Tom. Now show me that Spring bean config in XML 😉

I dont yet see the runtime injection use case. Could you give an example there?