[Design of JBoss jBPM] - Re: configuration phase 2
by tom.baeyens＠jboss.com
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.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224904#4224904
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224904
15 years, 2 months
[Design of JBoss jBPM] - configuration phase 2
by tom.baeyens＠jboss.com
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 ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224894#4224894
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224894
15 years, 2 months
[Design of JBoss jBPM] - Re: Mail session configuration
by bradsdavis
Actually instead of extending a specific mail producer, what if the templating did this:
| <template name="exampleTemplate">
| <mail-producer class="org.jbpm.pvm.internal.email.producer.impl.ScriptMailProducer">
| <subject>Example subject.</subject>
| <body>This is an example.</body>
| <language>JUEL</language> //or whatever
| <mail-producer>
| </template>
|
And then the templated mail producer itself could be plugable.
So within the templated mail producer we would have something like...
| public class TemplateMailProducer implements MailProducer {
|
| protected String templateName;
|
| public Collection<Email> produce(Execution exe, MailContext mailContext) throws Exception {
| //Find out which producer is being used in the template.
| MailProducer templatedProducer = readTemplate(templateName);
|
| return templatedProducer.produce(exe, mailContext);
| }
|
| protected MailProducer readTemplate(String templateName)
| {
| return null; //Actually do the reading and create the appropriate producer.
| }
| }
|
|
The nice thing about this solution is that we could reuse the mail-producer reader since it will be basically the same thing as if it were defined in the JPDL itself.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224728#4224728
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224728
15 years, 2 months
