[jboss-dev-forums] [Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss

[david.lloyd@jboss.com]

"tom.baeyens at jboss.com" wrote : "david.lloyd at jboss.com" wrote : The only change that absolutely requires a deployment of a new version is a change in the graph structure.  For any other change, it should be controllable by the user whether a new version is deployed.
  | 
  | i don't think it's good to have a model that has a complicated calculation on wether or not it will redeploy.

It doesn't have to be a complicated calculation.  You could use StAX to filter the XML file to remove whitespace and to filter out any elements that are not part of the XML namespace that defines the graph structure, and hash the result of that incrementally.  It could actually be more efficient than hashing the whole file because the complicated md5 calculation only takes place over a portion of the data!

"tom.baeyens at jboss.com" wrote : in development it doesn't matter if you redeploy too much.

Agreed.

"tom.baeyens at jboss.com" wrote : in production you won't update the file that often.

Well, yes and no.  I might want to update all the deployed processes with new GPD information for example, without causing a new version to be created for every process.  Or maybe I want to change other auxiliary information, again using other XML namespaces.

"tom.baeyens at jboss.com" wrote : so i don't really see a problem with just using a hashcode of the total process archive, preferrably in combination with the timestamp of the file.   without inspecting the contents of the deployed process

I disagree with the timestamp though.  That implies that any change to the file requires a new process version, and I don't believe that this is true.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052350#4052350

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052350