The forum (or my browser) ate my post, trying again...
"bill.burke(a)jboss.com" wrote : I'm reworking the JBoss+jBPM configuration
and deployment structure:
| (...)
| 2. Getting up and started with jBPM is painful in a JBoss environment.
| (...)
| b) You need to modify your ant build to save your .jpdl into the database so that the
jBPM server can pick things up. OR you do some other manual or programmatic process to
get your process definitions in the database.
|
You can deploy process definitions using the web console or graphical process designer as
well, but yeah...
"bill.burke(a)jboss.com" wrote : I want to create a ProcessDefinitionDeployer for
jboss. This will work like the SAR, EJB, EAR, etc... deployers. Users would be able to
deploy a .jar file named "xxx.bpm" or a foo.jpdl.xml file. The jar file would
contain a "META-INF/jbpm.jpdl.xml" file within it and any classes that could
possibily be used by the process definition.
|
| At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If
this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a
new version of the process definition is saved to the database.
I think this is a good idea. Though I've always disagreed with storing the process
archive (especially the classes) in the database. If you're going to make a
file-based deployer, it would be much better to just load the archive's classes the
normal way in my opinion. The database ought to hold just enough of the graph structure
to define the structure of the process and provide relations with its instances, and
that's it.
Also this is something that has always bothered me a bit - process versioning. If the
user has a process that is deployed into production, and there is a bug discovered after
deployment, say a coding error like an NPE, the user cannot deploy a replacement process.
They must deploy a new version, and manually (because there is no automated way) convert
each running process instance over to the new process version.
Your method of hashing the xml file would improve that substantially since coding bugs can
be corrected. I'm not so sure that hashing the XML file would be the best solution
though - I think it might be better generate a hash off of the actual semantic graph
structure (since it's really changes in the graph structure that would *require* a new
version), and also an (optional?) user-supplied version number (in case they want to
deploy a new version of a process that has the same structure but maybe different java
code behind it, so the XML file would otherwise be unchanged).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051935#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...