June 2007 - jboss-dev-forums - Jboss List Archives

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

by kukeltje

@david The process is more than the .xml file. It's also the versioned classes. So not only changes in the semantic graph structure, but also changes (which?) in the classfiles and other property/resource files should lead to a new version. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051937#4051937 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051937

18 years, 10 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

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#4051935 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051935

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: PD versioning and classloader scoping

by kukeltje

It becomes even more complex if you want to use specific versions of services on the ESB. Where is that configured, if at all? I do not know enough of the JBoss ESB to answer that myself. jBPM also has versioning of forms (deployed with the processarchive). There seems to be a small issue with that atm (versioning not realy working) but in real life applications it is not enough to just use the forms. Using a real (seam based) webapp is. But how to deploy 2 webapps on the same url (customers should not know which version they are using, the want to use webappA These are from real life experiences with JBoss jBPM, but the same has happend with Bea in combination with Staffware/Tibco the problems are the same (in fact even worse) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051934#4051934 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051934

18 years, 10 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

"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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051933#4051933 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051933

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Process Definition and Java class versioning

by kukeltje

jBPM already supports this if the classes are in the process archive. They are 'deployed' to the database and used with the corresponding version of the process. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051931#4051931 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051931

18 years, 10 months

1
0
0 / 0

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

by kukeltje

1. correct 2. only partly true. Let me elaborate a) not to difficult, but the problem was that the identity scripts were separate. This has been fixed recently (in cvs and will be in 3.2.1) b) Right, or use the GPD c) depends on the jboss version. for 4.0.4.GA you can just deploy the jbpm-console war file and be up and running. The profiles in the build scripts should be adapted/expanded to cope with other versions. People expecting to deploy the war from the starterkit (4.0.4) in 4.2 have a problem because of jsf libs... I think addressing this is more important for JBoss A real process deployer would be great. This has been discussed in the forums before. The thing is that you need a kind of versioning to check if a processarchive should be redeployed after starting or not. See the versioning issues in jira Please allow me to address a separate issue. jBPM has its own identity module. To some extend it is similar to the one in the portal. People often do not get this login thing and that was the reason it was dropped from 3.0 compared to 2.0. In 3.2 (or was it 3.1) it was reintroduced, but lining up the portal usermanagement and the one from jBPM would be realy nice. Maybe the usermanagement part should be a separate project (combine it with the sso?). This way both jBPM and portal can take separate advantage of it, but at the same time be compatible... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051929#4051929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051929

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Process Definition and Java class versioning

by bill.burke＠jboss.com

To be truly versionable, won't older process definitions have to work with old Java class versions? This goes along with my previous posts on the new .bpm archive type I want to introduce. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051927#4051927 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051927

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - PD versioning and classloader scoping

by bill.burke＠jboss.com

This post goes along with the .bpm archives feature talked about here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051925#4051925 When deploying a .bpm archive, you will also be able to include action, handler, and other utility classes within this archive. You will also be able to classloader scope these classes so that when the process instance is being executed on, it will run inside the configured classloader. How I/we will do this is still a mystery to me at the moment. At the Command Service layer, this is pretty straight forward. Just have some association someplace with the process definition and a classloader and push/pop the classloader when a message comes in. Referencing the process definitions, instances, tasks, tokens, etc... from standard JBPM APIs and being able to run with the correct classloader is a different problem and will need to be thought out more. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051926#4051926 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051926

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Rework of jBPM deployment within JBoss

by bill.burke＠jboss.com

I'm reworking the JBoss+jBPM configuration and deployment structure: 1. The hibernate and jbpm xml files are embedded deep within the enterprise archive. These need to be moved up for easy edits by the user 2. Getting up and started with jBPM is painful in a JBoss environment. (Please correct me on points here). a) You need to create the jBPM schema in the database 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. c) You need to copy and .jar files into the JBoss lib/ directory, WAR archive, or whatever. 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. A new config structure would look like this: | jbpm.deployer/ | hibernate.cfg.xml | jbpm.cfg.xml | jbpm-ds.xml | jbpm-jpdl.jar | jbpm-enterprise.ear | META-INF/ | jboss-service.xml | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051925#4051925 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051925

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: strategic ramblings

by bill.burke＠jboss.com

Others? * Seam integration. Currently you can only do Seam+jBPM within a web application. We need to start making the idea of Seam as a unification framework into a reality. Same needs to be done for ESB. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051917#4051917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051917

18 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2007