February 2009 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: From where can I start in jbpm ? (Design phase)

by yuqiaotech

now i think it is a better to start with jbpm4, read user guide and dev guide, then you can setup it. then study the examples code and the jbpm4 code, you could understand what is jbpm4 on earth. the only answer is to read the doc and try the software for the question opened by a newbier of how can i .... . and in fact it is the only way for you to start up. OMG, could you understand my Chiese English? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211665#4211665 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211665

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by alex.guizar＠jboss.com

anonymous wrote : Not too nice, but usable. Makes a good workaround in case pools are ruled out, but I would much rather go for your previous suggestion: anonymous wrote : I'm for configurable option, and not globally of course, but for each handler (with sensible default). Pooling would be the "sensible default" if the delegation description contained expressions. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211634#4211634 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211634

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by cvl

"alex.guizar(a)jboss.com" wrote : Won't caching make expression evaluation in delegation properties unfeasible? | | <delegation class="org.example.Taco"> | | <sauce>${actor.sauce.preference}</sauce> | | </delegation> | | If the above is not a requirement (I have wished for it more than once, and not just me, see JBPM-1752) then we can have a single object per process definition. Otherwise we need a pool. Well, how we solved this, is that we added the layer for all handlers, which injects the properties: | <action class="com.xxx.jbpm.proxy.JbpmHandlerProxy"> | <handlerName>myHandler</handlerName> | <propertyMap key-type='java.lang.String' value-type='java.lang.String'> | <entry><key>myProperty</key><value>#{myVar}</value></entry> | <entry><key>myProperty2</key><value>#{myVar2}</value></entry> | </propertyMap> | </action> Not too nice, but usable. cvl View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211622#4211622 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211622

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by cvl

This sounds somewhat like deciding for the user how to use the system. Why not add some flexibility - e.g. as with spring, you could point out the scope of the handler (like singleton). Pool is good for non singleton handlers (like jsf works). About the state in the action handler - we use that to autowire spring dependencies (@Autowire annotation) For now we are using only singleton scope, so that's not a problem (if you don't reload spring container), but what if you want to add some custom scope, let's say @ProcessInstance. Anyways, it's just an example, the idea is, why add some restrictions, where flexibility is wanted. I'm for configurable option, and not globally of course, but for each handler (with sensible default). cvl View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211621#4211621 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211621

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by alex.guizar＠jboss.com

Won't caching make expression evaluation in delegation properties unfeasible? <delegation class="org.example.Taco"> | <sauce>${actor.sauce.preference}</sauce> | </delegation> If the above is not a requirement (I have wished for it more than once, and not just me, see JBPM-1752) then we can have a single object per process definition. Otherwise we need a pool. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211611#4211611 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211611

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: process resume

by galanfish

i am sorry, i am new(just a college student)... but i...... i thought at first that some one develops a workflow-like thing with the pvm kernel would be called developer, and some one develops application-like with jbpm would called user... i want to develop a simple workflow with my own simple language View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211542#4211542 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211542

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by camunda

+1 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211517#4211517 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211517

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by koen.aers＠jboss.com

Actually, since at this moment the handler classes are instantiated at each use and thrown away afterwards, the use of them is stateless by definition. So if users use instance variables (fields) to hold variables temporarily they can somehow always be refactored as local variables in the execute method (or maybe as method calls in some superclass as in Robert's case). In these cases the change will indeed not be backwards compatible. The question is whether the performance gain of being able to cache these action handlers is worth the incompatibility. In my opinion it is. Of course, action handlers need to clearly be documented as stateless if we perform this change. Cheers, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211516#4211516 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211516

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by kukeltje

"camunda" wrote : But it is true still that it puts higher requirements on your ActionHandlers (no member fields)... 100% higher from 0 is still 0 :-) You can have member fields, in fact they are there since they are populated by the engine via reflection, they just should not change... So it's not that big a deal imo View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211514#4211514 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211514

15 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: process resume

by kukeltje

Please read the first line of my previous response... In case it was not clear ;-) this is the developer forum View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211511#4211511 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211511

15 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev February 2009