-
1. Re: JpdlXmlWriter bug?
koen.aers Jan 9, 2006 10:11 AM (in response to fmuhlenberg)The JpdlXmlWriter has been deprecated and it will be removed in one of the subsequent versions. So it will not be possible anymore to revert from an object model to the xml. On the contrary, it will be possible to save the xml definition in the database when deploying. This way you can always get back to the (versioned!) xml definition.
Regards,
Koen -
2. Re: JpdlXmlWriter bug?
hsf Feb 10, 2006 11:03 AM (in response to fmuhlenberg)I also have a question regarding the JpdlXmlWriter and the GPD...
When deploying a process definition we can deploy a jpdl xml file with the process modeled in GPD. If JpdlXmlWriter has been deprecated how do you plan to generate the xml process definition in the GPD? How do you plan to do it?
Thanks. -
3. Re: JpdlXmlWriter bug?
nick_nickolov Feb 14, 2006 5:30 AM (in response to fmuhlenberg)Dropping JbdlXmlWriter would also affect my project.
We are using it at application startup to decide whether the process definition structure has changed and we need to redeploy. We are fetching the pd as an object graph from the db, then converting it to xml, and comparing the xml to the original xml bundled with our app.
In case you really abandon it, I would suggest that you include a field in ProcessDefinition, representing a hash of the .par archive which it was parsed from (or include the full .par as a blob). It would make the comparison much easier.
Is anybody who's aware of jbpm's internals willing to provide a patch? Or should we do it ourselves and later share it? Do you think this solution is appropriate for the redeployment decision?
-- Nick -
4. Re: JpdlXmlWriter bug?
kukeltje Feb 14, 2006 10:54 AM (in response to fmuhlenberg)scary.... I would not use the JpdlXmlWriter for this.
I'd use the versionnumber of the latest processdefinition in the db and compare it to the one in the supposedly new one. If they match it 's the same, if they differ, look if the about to deploy version is newer. If so deploy it, if not report an error. -
5. Re: JpdlXmlWriter bug?
nick_nickolov Feb 14, 2006 11:04 AM (in response to fmuhlenberg)I'm afraid versionnumber wouldn't help.
Of course, the par which we haven't yet deployed does not have a version number (afaik, version numbers are not described in the process archive). And after deploying it, its versionnumber will become MAX(VERSIONNUMBER_) + 1.
The question is should we deploy the par at all. -
6. Re: JpdlXmlWriter bug?
ralfoeldi Feb 14, 2006 12:17 PM (in response to fmuhlenberg)Hi Nick,
you have a valid problem there and I do think the jBPM Team is aware of this.
Since I'm deploying in a J2EE env in a far, far away hosting I have the exact same problem. My solution was to add a version.properties file to the par, to parse that and explicitly set the version of the parsed processDefinition (thanks to Koen for the tip).
That way you can always get the 'version' of the par you have and compare that to the version in the database.... String processName = processDefinition.getName(); ProcessDefinition existingProcessDefinition = jbpmSession .getGraphSession().findLatestProcessDefinition(processName); if ((existingProcessDefinition == null) || (existingProcessDefinition.getVersion() < version)) { LOG.info("Deploying processDefinition:'" + processName + "', version:" + version + " from par archive '" + parName + "'"); processDefinition.setVersion(version); jbpmSession.getGraphSession().saveProcessDefinition( processDefinition); } else { LOG.info("ProcessDefinition:'" + processName + "' from par archive '" + parName + "' is alread deployed in version " + existingProcessDefinition.getVersion() + ". Not deploying version " + version); continue; } ...
You do have to keep track of your version though. By convention we use a 'timestamp' ymmddhhmm'. Works out ok.
Hope this helps you.
Greetings -
7. Re: JpdlXmlWriter bug?
nick_nickolov Feb 15, 2006 4:51 AM (in response to fmuhlenberg)Hi Rainer,
Good idea. But how and when do you calculate that "version" variable in your code? As far as I understand you calculate it from a timestamp, is it the timestamp when the build procedure is run?
In our team the build timestamp would be inappropriate. We are using a central db, local j2ee servers and local builds. If two developers do local builds consequtively, even without doing any changes to our business processes, the second one will always cause redeployment.
Sorry to bother you again.
-- Nick -
8. Re: JpdlXmlWriter bug?
ralfoeldi Feb 15, 2006 5:36 AM (in response to fmuhlenberg)Hi Nick,
no problem.
The 'timestamp' is manually set by whoever edits the workflow. That's why 'timestamp' was in quotes. (This approach does require some thinking by whoever does the editing.)
I guess you could use some kind of cvs macro/var for this, if you don't trust your business analysts :-)
Greetings -
9. Re: JpdlXmlWriter bug?
nick_nickolov Feb 15, 2006 9:59 AM (in response to fmuhlenberg)Business analysts are thinking about other stuff when they are editing pd-s. It's the frameworks responsibility to detect changes.
We want to make it as automated as possible, so we'll try a comparator implementation, and suggest it to the community if it proves successful.
Thanks :) -
10. Re: JpdlXmlWriter bug?
jbpm2011 Dec 28, 2011 11:31 AM (in response to fmuhlenberg)Hi,
so there is no other solution to write in the processDefinition.xml