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

[Design of JBoss jBPM] - Re: gpd deployer jar

by tom.baeyens＠jboss.com

did you check if the suite distribution still works ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051978#4051978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051978

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: seamability of the current jbpm jsf components

by tom.baeyens＠jboss.com

ok. that is already good news. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051977#4051977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051977

18 years, 10 months

1
0
0 / 0

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

by kukeltje

small addition: for me getting this new processarchive to the server is going through our deployment department, hence for me that was a deployment as well, but on a different level. I have to go to bed, it is 02:32 AM now..... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051948#4051948 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051948

18 years, 10 months

1
0
0 / 0

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

by kukeltje

aaaahhhhh, sorry, we ware talking about deployment from two different perspectives. I was looking at the complete processarchive as a version. You just looked at the processdefinition. Correct, by just replacing a classfile in combination with the same pd, no need for 'upgrading' processinstances to the newer one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051947#4051947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051947

18 years, 10 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

Imagine that a process was deployed, and thousands of people started using it. Now imagine that some Java action or something has a code bug that results in a RuntimeException, so thousands of process instances that have been begun cannot move forward. The developers should be able to replace that buggy Java code with a fixed version, which would then allow those process instances to continue execution. If a new version is produced, then someone has to manually migrate all those thousands of process instances to the new process version before they can move forward. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051944#4051944 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051944

18 years, 10 months

1
0
0 / 0

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

by kukeltje

Question: Why should a new processarchive with an identical pd.xml file but new classes not always require a new deployment? This is related to the problem how to decide a class is new. (build clean gives you a new timestamp but is something else identical?) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051942#4051942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051942

18 years, 10 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

"kukeltje" wrote : I agree, that he/she should have the option, but that should also be the case for changes in the .xml file. (small typo's in some text e.g.) and what about the forms.... | Exactly. That's why I said to hash the semantic graph structure, rather than the file itself. 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051941#4051941 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051941

18 years, 10 months

1
0
0 / 0

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

by kukeltje

I agree, that he/she should have the option, but that should also be the case for changes in the .xml file. (small typo's in some text e.g.) and what about the forms.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051940#4051940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051940

18 years, 10 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

"kukeltje" wrote : @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. I don't completely agree - I think that the user should be able to control (to the extent that it is possible) whether or not a new version is created, for the reason I already gave - the ability to patch an already-deployed process to fix production problems. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051939#4051939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051939

18 years, 10 months

1
0
0 / 0

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

by kukeltje

oops, me did not read the last line of your latest post View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051938#4051938 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051938

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