[tom.baeyens]

i think i understand your problem. let me rephrase to see if i understood correct:

in the whole jbpm sources, we only want 1 source version of all the configuration files so that we don't have to search and update 20 different configuration files if a cfg property needs to be updated or added.

so now you want a different configuration.

here's my current approach. let me know if you see a better way.

i take the basic configuration file that is used for the unit tests as a starting point. Each time when i need a different configuration, i create a copy and apply modifications of certain parts in that file.

Several modifications techniques can be used.

Plain replace:

<replace dir="${tmp.dir}">
 <includesfile name="**/*.hbm.xml"/>
 <replacetoken><![CDATA[type="string_max"]]></replacetoken>
 <replacevalue><![CDATA[]]></replacevalue>
 </replace>

Or update the comments. In that case you put a commented section in the original file like this

<!-- CMT transaction properties (begin) ===
 <property name="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</property>
 <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
 ==== CMT transaction properties (end) -->

so then you can use search and replace for the begin and end markers and replace the ==== pieces with the matching end of the comment. That way the commented section will be uncommented.

Most of the configurations that have to do with db properties can be specified from a .properties file rather then from inline in the properties in the hibernate.cfg.xml. In that case you can use any of the above 2 techniques to update the jbpm.cfg.xml and then add a reference to a properties file that is in cvs. then you can easily have a separate .properties configuration file instead of having your properties in the build script.

hope this helps.
let me know if something is not clear or needs improvement.

[mteira]

So, as an implementation example of all this (take in mind that ant is new stuff for me): To allow switching between JMS and DB based messaging, we could use a jbpm.cfg.xml file containing:

<jbpm-configuration>
 <jbpm-context>
 <!--DB based Messaging (begin) ==
 <service name="message" factory="org.jbpm.msg.db.DbMessageService"/>
 == DB based Messaging (end) -->
 <!--JMS based Messaging (begin) ==
 <service name="message">
 <factory><bean class="org.jbpm.msg.jms.JmsMessageServiceFactoryImpl">
 <field name="connectionFactoryJndiName"><string value="java:/XAConnectionFactory"/></field>
 <field name="destinationJndiName"><string value="queue/JbpmJobQueue"/></field>
 </bean></factory>
 </service>
 == JMS based Messaging (end) -->
 ...
 </jbpm-context>
</jbpm-configuration>

Now, how should we control what configuration to use? Could it be made using a property or something so? The examples I've found are uncommenting sections in an unconditional fashion. I think that this case is a little different, as we want to choose between two configuration modes.

Perhaps having local configuration files (in some place like local.config=${user.home}/jbpm/config ) should be simpler, and we could just try to use those files if they exist?

Regards.

[mteira]

Please, could someone make some comment about my thoughts about the JMS service implementation?

JmsMessageServiceImpl requires a JMS queue, used to send messages containing serialized jobs. Looking at the code, it seems that there's no developed component to listen into that queue and consume the jobs. Is this a missing part of the system? (An MDB to consume those jobs to replace the Servlet used now to execute the jobs).

Also, what's the conceptual difference between Commands and Jobs. I mean, couldn't the tasks performed by the Jobs be implemented as Commands to be consumed by the CommandListenerBean, and be executed in a CommandService Session?

I want to apologize for asking this more than once, but I've being requested to present a viability report for jBPM, and I need to understand how the JMS based Service works, and what is missing to be implemented.

Best regards.

--
Manuel.

[tom.baeyens]

1) the configuration updates. maybe, you should start with working out a fixed configuration file. then i could later make it generic. the picture is not yet clear to me so if you just do it straightforward (with duplication), that gives you the ability to move fast. And still i got the freedom later to bind it into the overall build process. The picture on how to customize jbpm.cfg.xml's is not yet clear to me now. Probably it will be something like you mentioned, but i'm not sure yet.

2) There is an MDB called command listener (cmdlistener) that reads commands from a queue and passes them to the SLSB called command service (cmdservice) for execution.

let me know if this helps you further

[mteira]

2) There is an MDB called command listener (cmdlistener) that reads commands from a queue and passes them to the SLSB called command service (cmdservice) for execution.

Yes, I know, as I commented before. But this MDB is only able to read Commands (org.jbpm.command.Command), and however, the objects that the JmsMessageServiceImpl is putting into its queue are Jobs (org.jbpm.job.Job with ExecuteActionJob and ExecuteNodeJob as final classes). So, I'm not sure if the idea is to have another MDB to consume those jobs (replacing the current JobExecutorThread and related servlet), or if perhaps the Commands are thought to replace these jobs. Now, there are two entities: MessageService and CommandService that seems very similar to me. So I would like to know what's the conceptual difference between these two things.

If the jobs and the MessageService are going to be used in the JMS scenario (probably, as we have a JMSMessageServiceImpl), we should need something to consume those jobs, task that is now performed by the JobExecutor and the ServletJobExecutor. I think an MDB is really more suitable into a J2EE and clustered environment.

I don't know if I'm explaining myself clearly. Please, make me know if this sounds confusing for you.

Best regards, and thanks a lot for your comments.
--
Manuel.

[tom.baeyens]

command and job are similar. code must be refactored so that the MDB and SLSB work together. the confusion is caused by the fact that the impl of cmdlistener and cmdservice are not yet complete. the first thing we need is a testing set up and completing the impl that is there.

so we don't need other beans. we only need to make sure that Job implements Command or change something else so that it works. In the next two weeks, i will have some time to help and actually do some work together with you on this. So if you can keep the fight up for a few more days.... help is on its way.

[mteira]

command and job are similar. code must be refactored so that the MDB and SLSB work together. the confusion is caused by the fact that the impl of cmdlistener and cmdservice are not yet complete. the first thing we need is a testing set up and completing the impl that is there.

If you can identify here some concrete work that I could do, please make me know.

so we don't need other beans. we only need to make sure that Job implements Command or change something else so that it works.

OK. I'll take a look at it.

In the next two weeks, i will have some time to help and actually do some work together with you on this. So if you can keep the fight up for a few more days.... help is on its way.

Nice to hear that. Thanks a lot.

--
Manuel.

[tom.baeyens]

i'm starting on this today. first thing i'm going to try to do is set up a test environment for testing the JMS based message service inside of jboss. this will probably involve cactus.

[mteira]

Great to read that.
I'm a little busy now with other projects, but will like to hear about your progress, and will try to keep my environment updated to test what you're doing.

Regards.

[aguizar]

this will probably involve cactus

You don't have to. JMS queues can be accessed from outside JBoss using the UIL2 layer in JBossMQ.

This is how I tested the JMS stuff in BPEL, altough your test requirements might be different.