[JBoss jBPM] - Re: Problem in getting proper workflow transitions:
by maxp
Hi Duc
Here is the process definition.xml file for the same
| <process-definition
| xmlns="urn:jbpm.org:jpdl-3.1" name="credit-request-approval">
|
| <start-state name="start">
| <transition name="enter-request" to="task-node1"></transition>
| </start-state>
|
| <task-node name="task-node1">
| <task name="enter-details" ></task>
| <transition name="send for approval" to="task-node2"></transition>
| </task-node>
| <task-node name="task-node2">
| <task name="approval1"></task>
| <transition name="approved" to="task-node3"></transition>
| <transition name="rejected" to="Request rejected"></transition>
| </task-node>
| <task-node name="task-node3">
| <task name="approval2"></task>
| <transition name="approved" to="Request Approved"></transition>
| <transition name="rejected" to="Request rejected"></transition>
| </task-node>
| <end-state name="Request Approved"></end-state>
| <end-state name="Request rejected"></end-state>
| </process-definition>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051194#4051194
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051194
19Â years
[JBossCache] - CR2 POJO Cache Notification Changes
by jason.greeneï¼ jboss.com
Hello Everyone,
CR2 finally adds the long awaited ability for remote POJO notifications. In order to provide this functionality the implementation design was changed to be an extension of the core Cache Listener API instead of relying on the introduction of AOP mixins (which can be local only and prevent the possibility of transactional behavior).
Also included in this release is the ability to register a POJO listener using a regex based filter on the FQN of the change.
A side effect of these improvements is the loss of the multiple PRE POST phase delivery. There are 3 main reasons why this had to change:
1) A single POJO change can consist of many internal core cache node updates, so it's not always possible to identify a change unless all of them are made, and therefore any POJO PRE phase would be inaccurate.
2) The current Cache Listener API in core cache doesn't have the ability to see a future change while in the PRE phase. The POJO notification implementation would have to wait for the POST phase to see the change and this also makes any POJO PRE phase inaccurate.
3) The common goal of both the core cache and pojo cache notification system is to deliver notifications *only* on TX boundaries.. This makes a PRE phase not as useful, since you are just being informed what changed.
Overall I view this as more of a simplification. The only real loss of functionality is the ability to tell what the value was before a field change but this kind of change tracking can easily be implemented in an application specific manner by just tracking the events you care about in a pojo cache listener
On another topic, the upcoming CR3 release will include support for collection operation notifications. The code is already in HEAD if you want to play with it now.
I appreciate any feedback you have to offer on this as we are approaching GA soon.
Thanks,
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051187#4051187
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4051187
19Â years