Re: [rules-users] npe in LogicalRetractCallback when using jpa persistence
Hi Edson,
thanks für your response. I'll try to provide a testcase... if you don't
get a jira ticket, the test revealed it was user error. :-)
- chris
Am 10.08.2010 16:16, schrieb Edson Tirelli:
Chris,
I will look into this problem, but I am not sure how to reproduce
it. Maybe you can provide me a test case? If so, please open a JIRA,
attached your test case and ping me.
Thanks,
Edson
2010/8/10 Chris Raschl c.ras...@dyless.com mailto:c.ras...@dyless.com
Hi,
Just in case someone faces the same problem, comments inline:
Am 05.08.2010 13:53, schrieb Chris Raschl:
I'm using the latest drools and drools flow snapshot with jpa
persistence.
When I'm retracting a fact from the knowledge session (which causes
logical retraction), the session can't be persisted any more.
During retraction a LogicalRetractCallback is instantiated using this
constructor:
public LogicalRetractCallback(final TruthMaintenanceSystem tms,
final LogicalDependency node,
final Set set,
final InternalFactHandle handle,
final PropagationContext context,
final Activation activation) {
this.tms = tms;
this.node = node;
this.set = set;
this.handle = handle;
this.context = context;
}
As you can see an activation object can be passed (and actually is
passed) to the constructor, but is never used. Retraction works
though.
The problem occurs when the knowledge session is persisted, because
LogicalRetractCallback.write assumes that activation is not null,
which
leads to this npe:
Caused by: java.lang.NullPointerException
org.drools.common.TruthMaintenanceSystem$LogicalRetractCallback.write(TruthMaintenanceSystem.java:251)
org.drools.marshalling.impl.OutputMarshaller.writeActionQueue(OutputMarshaller.java:201)
Adding this.activation = activation to the constructor does not help,
beause the npe in the write method remains. I tried it, then the whole
expression context.terminalTupleMap.get( this.activation.getTuple() )
in the write method evaluates to null...
I found out persistence was triggered by an unneccessary flush in my
code. I removed that, everything works now.
That seems to be the case because the action queue is empty then and
there's no need to persist it, thus the write method is never called. I
guess the problem remains if someone tries to persist a session with an
action queue containing a LogicalRetractCallback object.
- chris
___
rules-users mailing list
rules-users@lists.jboss.org mailto:rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com http://www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] npe in LogicalRetractCallback when using jpa persistence
Hi,
Just in case someone faces the same problem, comments inline:
Am 05.08.2010 13:53, schrieb Chris Raschl:
I'm using the latest drools and drools flow snapshot with jpa persistence.
When I'm retracting a fact from the knowledge session (which causes
logical retraction), the session can't be persisted any more.
During retraction a LogicalRetractCallback is instantiated using this
constructor:
public LogicalRetractCallback(final TruthMaintenanceSystem tms,
final LogicalDependency node,
final Set set,
final InternalFactHandle handle,
final PropagationContext context,
final Activation activation) {
this.tms = tms;
this.node = node;
this.set = set;
this.handle = handle;
this.context = context;
}
As you can see an activation object can be passed (and actually is
passed) to the constructor, but is never used. Retraction works though.
The problem occurs when the knowledge session is persisted, because
LogicalRetractCallback.write assumes that activation is not null, which
leads to this npe:
Caused by: java.lang.NullPointerException
org.drools.common.TruthMaintenanceSystem$LogicalRetractCallback.write(TruthMaintenanceSystem.java:251)
org.drools.marshalling.impl.OutputMarshaller.writeActionQueue(OutputMarshaller.java:201)
Adding this.activation = activation to the constructor does not help,
beause the npe in the write method remains. I tried it, then the whole
expression context.terminalTupleMap.get( this.activation.getTuple() )
in the write method evaluates to null...
I found out persistence was triggered by an unneccessary flush in my
code. I removed that, everything works now.
That seems to be the case because the action queue is empty then and
there's no need to persist it, thus the write method is never called. I
guess the problem remains if someone tries to persist a session with an
action queue containing a LogicalRetractCallback object.
- chris
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Help Needed in Drools Flow
Am 14.07.2010 12:05, schrieb santosh mukherjee: Hi, I want to add some of my own customized components to Drools Flow components pannel. How can this be done. Is there some API available to do so ?? Hi, i guess you want to add domain specific work items to use them in the process designer in eclispe. There is no API, to do that you just have to add a drools.rulebase.conf file and your own work item definition to your META-INF directory. There is an example in the drools flow manual: http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-flow/html_single/index.html#d4e1033 Remind: You'll have to re-open the process to make the work items appear. Hope this helps, chris ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] WorkItemNodeInstance and the on exit action
Hi Salaboy, thanks for your response. Summing up I can say it was mostly lack of understanding on my side... Kris's fix just made it visible. Please let me know if I'm on the right track, my comments are inline. Am 09.07.2010 16:56, schrieb Salaboy: Hi man, Did you recognize this error after update? Yes, we decided to use the latest snapshots until the next stable release is reached. Why are you doing that if you have the human tasks Apis to complete a task that automatically set the result values. I would like to take a look at your issue, can you provide me more info about it? We wanted to remove mina, since it added unnecessary complexity to our case. To create human tasks we implemented our own human task handler, based on the CommandBasedWSHumanTaskHandler and its ResponseHandlers, but we've injected (we're using seam) a TaskServiceSession directly. Additionally we added some logic to persist sessionId, processId, workItemId and taskId when a task is created to load the session correctly when the task is finished. That worked fine so far until the upgrade, caused by the patch by kris. I digged into the code again, there are three places I found related to passing data from the human task to the process. 1.) GetResultContentResponseHandler, which finishes the work item and passes entered data to the WorkItemManager. If a map is given it's contents are also added to the result. 2.) The JPAWorkItemManager itself which sets the results into the workItem using workItem.setResults(results) and then signals completion. 3.) Then triggerCompleted is called on the work Item and out-mappings are processed. Knowing this i tried some mappings: 1.) Map the whole result and process it later in the on exit action or a seperated action node. mapping type=out from=Result to=latestHumanTaskResult / 2.) Or map the required variable, either from the result map or directly. mapping type=out from=Result['key'] to=processVariable / mapping type=out from=key to=processVariable / Both work like a charm. From this point of view I don't know why we used the WorkItemNodeInstance and WorkItem in our exit action, there is no need to. Further it adds an unnecessary dependency to the process definition. Problem solved. Thanks, chris On Jul 9, 2010, at 11:22, Chris Raschl c.raschl-mailingli...@dyless.com wrote: Hi Kris, we experienced some troubles with our drools flow integration today (we upgraded to the lastest snapshot) and I found out that is has to do with a fix (see [1]) you commited some time ago. Our problem is, that we access the data submitted by the user to finish a human task in the on exit action of the human task node like this: WorkItemNodeInstance wini = (WorkItemNodeInstance)context.getNodeInstance(); MapString, Object result = (MapString, Object)wini.getWorkItem().getResult(Result); This results in a NPE because the workItemId is set to -1 in the WorkItemNodeInstance before getWorkItem() is called. So getWorkItem() returns null. Is there a better (recommended) way to work with human task data? Maybe using an out-mapping? Thanks, chris [1] http://fisheye.jboss.org/browse/JBossRules/trunk/drools-core/src/main/java/org/drools/workflow/instance/node/WorkItemNodeInstance.java?r1=32801r2= ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] WorkItemNodeInstance and the on exit action
Hi Kris, we experienced some troubles with our drools flow integration today (we upgraded to the lastest snapshot) and I found out that is has to do with a fix (see [1]) you commited some time ago. Our problem is, that we access the data submitted by the user to finish a human task in the on exit action of the human task node like this: WorkItemNodeInstance wini = (WorkItemNodeInstance)context.getNodeInstance(); MapString, Object result = (MapString, Object)wini.getWorkItem().getResult(Result); This results in a NPE because the workItemId is set to -1 in the WorkItemNodeInstance before getWorkItem() is called. So getWorkItem() returns null. Is there a better (recommended) way to work with human task data? Maybe using an out-mapping? Thanks, chris [1] http://fisheye.jboss.org/browse/JBossRules/trunk/drools-core/src/main/java/org/drools/workflow/instance/node/WorkItemNodeInstance.java?r1=32801r2= ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Drools Flow: how to get knowledge session ID from WorkItem
Hi Alan,
On 2010-05-04 13:10, alan.gai...@tessella.com wrote:
The subject says it all really: is there any way of determining the
knowledge session ID from the WorkItem argument (or WorkItemManager
argument?) passed in to the executeWorkItem method of an implementation
of the WorkItemHandler interface?
I had the same problem so i simply extended the work item handler interface
like this:
public interface SessionAwareWorkItemHandler extends WorkItemHandler {
StatefulKnowledgeSession getKnowledgeSession();
void setKnowledgeSession(StatefulKnowledgeSession session);
}
If you register a SessionAwareWorkItemHandler, just let him know about the
session:
if (handler instanceof SessionAwareWorkItemHandler) {
SessionAwareWorkItemHandler sessionAware =
(SessionAwareWorkItemHandler)handler;
sessionAware.setKnowledgeSession(ksession);
}
ksession.getWorkItemManager().registerWorkItemHandler(workItem, handler);
Hope this helps, it works for me.
- chris
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Flow, Human Task, Group Assignment
Hi, I've got a question concerning drools flow, human tasks and group assignments. I assigned a human task to a group (via the groupId parameter) and can successfully retrieve it using the TaskServiceSession function: getTasksAssignedAsPotentialOwner(userId, groupIds, language) This function implies in my understanding that the knowledge about group membership is not (yet?) managed within the human task management component, otherwise there would be no need to pass the groupIds to it. If a user tries to claim the task now, a PermissionDeniedException is thown because drools currently has no information about his group membership. see TaskServiceSession, line 602: isAllowed(final User user, final ListOrganizationalEntity entities) There is even a comment in there... for now just do a contains, I'll figure out group membership later. Is there a way to work around this issue? I'd like to avoid implementing my own TaskServiceSession because of the lack of an interface and a dependency to SubTasksStrategies. Thanks in advance, Chris ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
