]
Mauricio Salatino commented on JBRULES-2608:
--------------------------------------------
In the scenario that you mention, if you remove the out mapping from the second work item
it should work.
Why this is a problem?
PROBLEM: "Third workitem needs to pick up the same list that was PERSISTED and is not
able to do so"
In the second work item you receive the list as in parameter, do whatever you want and
then you want to complete your work item use those results to call the
manager.completeWorkItem().
WorkItemHandler has like channels from ins and outs and it store what it's going in on
the database. But it's your responsibility to mangle and store all the intermediate
information that it's being handled.
Remember workitemhandler are outside the scope of the framework and it's not the
framework responsibility to handle all the information inside them.
Just my two cents.
Variable Persistence Overwrites NULL Values over Persisted Values
-----------------------------------------------------------------
Key: JBRULES-2608
URL:
https://jira.jboss.org/browse/JBRULES-2608
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: All
Affects Versions: 5.1.0.FINAL
Environment: N/A
Reporter: Anatoly Polinsky
Assignee: Mauricio Salatino
Attachments: difference-between-first-and-second-work-item.png,
drools-vp-jira.zip, passing-list-process-test.png, passing-list-process.png
Original Estimate: 4 hours
Remaining Estimate: 4 hours
Drools Flow
=========
For non-String variables (Serializ..ble, Entities, etc..), Drools overwrites NULLs
when a (JPA) process is resumed ( a workitem is completed ).
1. Here is a use case: a List ( ArrayList ) is passed to the process in start as a
parameter
2. First work item sees ( maps in ) the List, and can work with it inside the work
item handler
3. First work item does not complete: process goes to sleep.
4. When the session is reloaded, the first work item is completed
5. All the persisted variables ( including the "list" ) are restored
6. Second work item is taking in the list ( it maps in )
7. However at this point it is NULL
It seems that when the context is closed, after resolving variables, the following
(WorkItemNodeInstance):
VariableScopeInstance variableScopeInstance = ( VariableScopeInstance )
resolveContextInstance( VariableScope.VARIABLE_SCOPE,
mapping.getValue() );
does no longer have the restored variables, and rather NULLs, since internally
variables are compared with a "result map" that was passed to the previous work
item.
This means that persisted variables are restored internally, but then overwritten
internally by NULLs.
/Anatoly
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: