-
15. Re: statefull vs stateless delegation classes
camunda Feb 19, 2009 10:27 AM (in response to tom.baeyens)+1
-
16. Re: statefull vs stateless delegation classes
aguizar Feb 19, 2009 1:53 PM (in response to tom.baeyens)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. -
17. Re: statefull vs stateless delegation classes
fang0x0 Feb 19, 2009 2:49 PM (in response to tom.baeyens)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 -
18. Re: statefull vs stateless delegation classes
fang0x0 Feb 19, 2009 2:58 PM (in response to tom.baeyens)"alex.guizar@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 <a href="https://jira.jboss.org/jira/browse/JBPM-1752">JBPM-1752</a>) 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 -
19. Re: statefull vs stateless delegation classes
aguizar Feb 19, 2009 4:03 PM (in response to tom.baeyens)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: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. -
20. Re: statefull vs stateless delegation classes
tom.baeyens Feb 20, 2009 3:52 AM (in response to tom.baeyens)alejandro, your point is correct. when sharing a single instance, context sensitive expressions cannot be used as they were.
i see two options:
1) not doing any expression resolution in the injections. only make it possible to inject the static string "${actor.sauce.preference}" in a member field.
and then make expression resolution available to the delegation classes through an api method invocation.
2) create a property to specify whether a delegation is stateless or not.
i'm leaning towards 1) because that is a performant default which users cannot get into trouble with. -
21. Re: statefull vs stateless delegation classes
jbarrez Feb 20, 2009 4:11 AM (in response to tom.baeyens)1) is the way I'm currently doing it today, but it feels like I'm doing the engine's work by doing so ...
Users won't get in to trouble by using option 1, but it certainly overloads the execute method, even if you want to do something simple like adding 2 runtime variables and store the result: first fetch and 'interprete' them, add them, store them ... this is not the jbpm-way
Option (2) is a viable alternative, but it's a bit error-prone and hard to debug IMO. Stateful should be the default choice then, and those who want extra performance can set the stateless option where needed
So, I'm not liking any of the 2 options ... but if I had to choose, I'd choose option (2).