2 Replies Latest reply on Apr 10, 2009 10:36 AM by tom.baeyens

    configuration phase 2

    tom.baeyens
    tom.baeyens Apr 10, 2009 9:42 AM

      building the config tool i realized that i didn't fully tackled the problem. users are still confronted with all the jbpm configuration files. and this will be a pain when we want to update configuration stuff in subsequent versions.

      The original goal motivation for building the config tool was to offer a basic set of configuration options. Only the configurations that are changeable by our users.

      These are the configuration properties that the config tool takes as input:

      database=hsqldb
cache=hashtable
connection.type=jdbc
deployment.type=standalone
hibernate.session=default
jpdl=include
identity=include
format.sql=include
log.cfg=logging.properties


      Bindings in our parsing are easy to customize. But most of these user-changeable properties impacts various contexts in the jbpm config file. For example, to include the identity, we need to add some parts to the process engine context and some parts to the transaction context. 

      <jbpm-configuration>
 <process-engine-context>
 <identity-service />
 <identity-session-factory resource="jbpm.identity.cfg.xml" />
 ...
 </process-engine-context>
 <transaction-context>
 <identity-session />
 ...
 </transaction-context>
</jbpm-configuration>


      In the next step of configuration i would like to achieve 2 goals:

      * create a jbpm.cfg.xml that reflects the properties that we want to expose for support users to change

      * avoid default configurations in the jbpm.cfg.xml so that it becomes easier to update configurations later on.

      I think this is possible with following approach
      1) adding import of jbpm.cfg.xml files
      2) provide a lot of default configuration files in the jbpm jars.

      For example with imports we a user would have to configure the identity component like this: 

      <jbpm-configuration>
 <import resource="jbpm.identity.buildin.cfg.xml" />
 ...
</jbpm-configuration>


      or 

      <jbpm-configuration>
 <import resource="jbpm.identity.jboss.idm.cfg.xml" />
 ...
</jbpm-configuration>


      and the refered files like 

      <jbpm-configuration>
 <process-engine-context>
 <identity-service />
 <identity-session-factory resource="jbpm.identity.cfg.xml" />
 </process-engine-context>
 <transaction-context>
 <identity-session />
 </transaction-context>
</jbpm-configuration>


      can then be provided in the jars we ship.

      thoughts ?

      • 449 Views
      • Tags:
        • 1. Re: configuration phase 2
          tom.baeyens
          tom.baeyens Apr 10, 2009 10:10 AM (in response to tom.baeyens)

          related to this are the database property resolution. currently this is done as part of the build *before* the installer is build. i think this is broken. there should be a single distribution that is usable for all qa runs.

          if we want to keep the installer, we should expand it so that it can also configure the db properties and that way enable that all qa runs can be started from one single distribution. i've looked a bit at izpack and it doesn't seem an easy task to me.

          we should consider alternatives for installing jbpm into the AS in the automated QA runs. distributing an ant task that takes files from the distribution directory and copies them into the as seems feasible to me.

            • Actions
          • 2. Re: configuration phase 2
            tom.baeyens
            tom.baeyens Apr 10, 2009 10:36 AM (in response to tom.baeyens)

            Ideally I think the qa / configuration should be organised like this:

            A first job builds the distribution and runs the tests (default in memory mode) while building the distribution. Let's call this the distribution job.

            Then the container matrix is a dependent job that only runs when the first job succeeded. The container matrix runs will start from the distribution that is build in the distribution job.

            The distribution is unzipped. In the distribution there is an ant script that can install jbpm into jboss as. That uses some property files that specify the connection settings. Then the qa overwrites those properties file with the specific properties of that job (similar to how we now do it with the profiles). And then the qa invokes the ant script that installs jbpm into the AS for that specific test run.

            That way, the properties files with the specific configurations for the qa lab database are also somewhere in the hudson directory, but not in the same format. And they would be used after the distribution is unpacked. It would also simplify a lot the comlexity of property resolution in our current build.

              • Actions