6:20 a.m.
Kris,
Thanks yes - the null check fixes the NPE I was seeing.
Unfortunately, I now have a more difficult problem. In my work item
handler, I use the following code to get the ID of a work item in the rule
flow (i.e. the .rf file itself) given a
org.drools.runtime.process.WorkItem instance:
private long getCurrentNodeId(WorkItem workItem) {
ProcessInstance processInstance =
ksession.getProcessInstance(workItem.getProcessInstanceId());
if (processInstance instanceof WorkflowProcessInstanceImpl) {
Collection<NodeInstance> nodeInstances =
((WorkflowProcessInstanceImpl) processInstance).getNodeInstances();
for (NodeInstance nodeInstance : nodeInstances) {
System.out.println(String.format("Node instance: %s",
nodeInstance));
if (nodeInstance instanceof WorkItemNodeInstance) {
WorkItemNodeInstance workItemNodeInstance =
(WorkItemNodeInstance) nodeInstance;
if (workItemNodeInstance.getWorkItem() == workItem) {
return workItemNodeInstance.getNodeId();
}
}
}
}
throw new RuntimeException(String.format("Error determining node
ID for work item: %s", workItem.toString()));
}
The work item in the attached test case, the first time it executes sets a
property on a fact in memory that causes a subsequent Split node to send
the flow to an Event Wait. The code in the overall main() method (in
PersistenceTest.java) then updates the fact in memory so that the Event
Wait's constraint is satisfied, and the work item node is executed again.
The second time around, it sets the property on the fact in memory so that
the subsequent Split node sends the flow to its end. (I hope this makes
sense; looking at the rule flow in the test case should show you what I'm
trying to do.)
If I execute the test case with my session created using the code:
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
everything works as I would expect, and the output from the
System.out.println() statement in my getCurrentNodeId() method above is:
Node instance:
org.drools.workflow.instance.node.WorkItemNodeInstance@125d568
Node instance:
org.drools.workflow.instance.node.WorkItemNodeInstance@37a04c
However, if I use JPA persistence:
StatefulKnowledgeSession ksession =
JPAKnowledgeService.newStatefulKnowledgeSession(kbase, null, env);
then the RuntimeException in getCurrentNodeId() is thrown, and the output
is:
Node instance:
org.drools.workflow.instance.node.WorkItemNodeInstance@2209db
Node instance:
org.drools.workflow.instance.node.MilestoneNodeInstance@d8fd1a
Somehow it seems as though the node instance isn't quite synchronised with
the overall state when using JPA persistence.
Any help you could give me here would be very much appreciated.
Regards,
Alan
Kris Verlaenen <kris.verlaenen(a)cs.kuleuven.be>
30/10/2009 20:10
To
Alan.Gairey(a)tessella.com
cc
Subject
Re: [rules-users] [droolsflow] Code-based constraints for EventWait nodes
- is this possible?
Alan,
Thanks, this indeed seems to be the issue. I have changed this on
trunk. Does adding this null check solve your issue?
Thx,
Kris
Quoting Alan.Gairey(a)tessella.com:
Kris,
Some more information: the NullPointerException from GetObjectCommand
is
thrown by the line:
((StatefulKnowledgeSessionImpl)ksession).session.getExecutionResult().getResults().put(
this.outIdentifier,
object );
Method getExecutionResult() is returning null. Debugging my test
case, I
also notice that this.outIdentifier is also null.
I then had a look at the GetObjectsCommand class; in its execute
method,
there is a line similar to that above. However, it is contained
within an
if block that checks this.outIdentifier is not null:
if ( this.outIdentifier != null ) {
List objects = new ArrayList( col );
((StatefulKnowledgeSessionImpl)ksession).session.getExecutionResult().getResults().put(
this.outIdentifier, objects );
}
If something similar was done in GetObjectCommand, presumably this
would
fix my problem?
Hope this is of some use - regards,
Alan
Alan.Gairey(a)tessella.com
Sent by: rules-users-bounces(a)lists.jboss.org
29/10/2009 17:35
Please respond to
Rules Users List <rules-users(a)lists.jboss.org>
To
Kris Verlaenen <kris.verlaenen(a)cs.kuleuven.be>
cc
Rules Users List <rules-users(a)lists.jboss.org>
Subject
Re: [rules-users] [droolsflow] Code-based constraints for EventWait
nodes
- is this possible?
Kris,
Thanks - making the class SimpleFact serializable fixed that error.
However, I now have a new problem: I have a rule flow containing a
work
item - the handler attempts to update the SimpleFact instance in
memory
before completing the task. The code in the executeWorkItem method is
as
follows:
Collection<FactHandle> factHandles =
ksession.getFactHandles(new
ObjectFilter() {
public boolean accept(Object object) {
return (object instanceof SimpleFact);
}
});
for (Iterator<FactHandle> iterator = factHandles.iterator();
iterator.hasNext(); ) {
FactHandle factHandle = iterator.next();
SimpleFact fact = (SimpleFact)
ksession.getObject(factHandle);
fact.setStatus("Error");
ksession.update(factHandle, fact);
}
workItemManager.completeWorkItem(workItem.getId(), null);
The call to getObject() causes the following exception to be thrown:
java.lang.NullPointerException
at
org.drools.command.runtime.rule.GetObjectCommand.execute(GetObjectCommand.java:35)
at
org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:254)
at
org.drools.command.impl.CommandBasedStatefulKnowledgeSession.getObject(CommandBasedStatefulKnowledgeSession.java:369)
at
com.test.StatusChangeWorkItemHandler.executeWorkItem(StatusChangeWorkItemHandler.java:37)
...
I've attached another test case to illustrate the problem.
Once again, my sincere thanks for helping me with this.
Regards,
Alan
Kris Verlaenen <kris.verlaenen(a)cs.kuleuven.be>
29/10/2009 12:00
To
Alan.Gairey(a)tessella.com
cc
Rules Users List <rules-users(a)lists.jboss.org>
Subject
Re: [rules-users] [droolsflow] Code-based constraints for EventWait
nodes
- is this possible?
Alan,
The cause of the rollback of the transaction is this:
Caused by: java.io.NotSerializableException: com.test.SimpleFact
The reason is that, if you use persistence for your session, the
persister will try to save all runtime state of the engine. This
does
not only include process instances, but also rule-related state. By
default, this also includes the data inserted in the memory. We
support
two strategies for storing this data: serialization of the data
(default) or JPA-based storage of entities (by reference). In this
case, the persister is trying to serialize the test object you
inserted
and fails. Making it serializable should fix this.
Kris
Quoting Alan.Gairey(a)tessella.com:
> Kris,
>
> I've attached a simple test case (transaction manager, data
source,
> etc.
> are configured via Spring). The error is thrown on line:
>
> ksession.insert(new SimpleFact());
>
> If this line is commented out, the rule flow executes without
error.
>
>
>
> Many thanks for looking at this.
>
> Regards,
>
> Alan
>
>
>
>
> Kris Verlaenen <kris.verlaenen(a)cs.kuleuven.be>
> 28/10/2009 10:40
>
> To
> Alan.Gairey(a)tessella.com
> cc
> Rules Users List <rules-users(a)lists.jboss.org>
> Subject
> Re: [rules-users] [droolsflow] Code-based constraints for
EventWait
> nodes
> - is this possible?
>
>
>
>
>
>
> Alan,
>
> Could you send me the entire output / stack trace (as the rollback
> of
> the transaction is usually caused by another exception)?
>
> Or a simple test case that shows the error, so I can take a look?
>
> Thx,
> Kris
>
> Quoting Alan.Gairey(a)tessella.com:
>
> > Kris,
> >
> > After posting my last question, I quickly came to the same
> conclusion
> > as
> > you, so I'm now using a rule-based constraint in my EventWait
> node.
> >
> > This however has presented a different problem. If I create my
> > session
> > from JPAKnowledgeService, then when I try to insert my fact into
> the
> >
> > session, I get the following error:
> >
> > bitronix.tm.internal.BitronixRollbackException: transaction was
> > marked as
> > rollback only and has been rolled back
> > at
> >
>
bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:153)
> > at
> >
>
bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:96)
> > at
> >
>
org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:258)
> > at
> >
>
org.drools.command.impl.CommandBasedStatefulKnowledgeSession.insert(CommandBasedStatefulKnowledgeSession.java:305)
> > (Everything works fine if I create my session from the
knowledge
> base
> > -
> > i.e. with no state persistence.)
> > Prior to using a rule-based constraint (with no call to
> > CommandBasedStatefulKnowledgeSession.insert), the session
created
> > from
> > JPAKnowledgeService worked OK.
> > I'm using the default JPA configuration from the Drools
> documentation
> >
> > (persisting to H2 database, etc.).
> > Any ideas what might be causing the problem?
> > Many thanks,
> > Alan
> >
> >
> >
> >
> > Kris Verlaenen <kris.verlaenen(a)cs.kuleuven.be>
> > 23/10/2009 03:00
> >
> > To
> > Rules Users List <rules-users(a)lists.jboss.org>,
> > Alan.Gairey(a)tessella.com
> > cc
> > Rules Users List <rules-users(a)lists.jboss.org>
> > Subject
> > Re: [rules-users] [droolsflow] Code-based constraints for
> EventWait
> > nodes
> > - is this possible?
> >
> >
> >
> >
> >
> >
> > No, the constraint of an EventWait node (or the State node in
> Drools
> > 5.1) can only be rule-based. The reason for this is that the
rule
> > engine knows when to re-evaluates rules (based on the evailable
> > input).
> > If you would use a code-based constraint, the engine would have
> no
> > idea
> > when this code constraint might become true (if it was false at
> the
> > start). Only constant re-evaluation of the code constraint
could
> > achieve this (which would be tremendously inefficient). Could
you
> > explain why you would like to have this behaviour? Maybe there
is
> > an
> > alternative way to model this.
> >
> > To change the value of a variable from inside the process (using
> an
> > action), simply use kcontext.setVariable(name, value). We do
not
> > recommend manually changing the value of a process variable from
> > outside
> > the engine. Again, could you explain why you would like to have
> > this
> > functionality?
> >
> > Kris
> >
> > Quoting Alan.Gairey(a)tessella.com:
> >
> > > Can the constraint for an EventWait node in a flow be
code-based
> > > (rather
> > > than rule-based)? The Eclipse plug-in (v 5.0.1) doesn't allow
> this
> > to
> > > be
> > > specified, unlike say for a Split node, although the relevant
> XML
> > can
> > > of
> > > course be edited.
> > > Trying to load such a process flow results in a
> > NullPointerException,
> > >
> > > because the constraint is always interpreted as a rule.
> > >
> > > Ideally what I'd like to do is have an EventWait node where
the
> > > constraint
> > > tests the value of a process variable. This then leads me to
> > another
> > >
> > > question; is there a way of setting the value of a process
> > variable
> > > via
> > > the Drools Flow API?
> > >
> > > Thanks in advance for any help,
> > >
> > > Alan
> > > Tessella plc
> > > 26 The Quadrant, Abingdon Science Park, Abingdon, Oxfordshire,
> > OX14
> > > 3YS
> > > E: Alan.Gairey(a)tessella.com, T: +44 (0)1235 555511, F: +44
> (0)1235
> > > 553301
> > > www.tessella.com Registered in England No. 1466429
> > >
> > > This message is commercial in confidence and may be
privileged.
> It
> > is
> > >
> > > intended for the addressee(s) only. Access to this message by
> > anyone
> > > else
> > > is unauthorized and strictly prohibited. If you have received
> this
> > > message
> > > in error, please inform the sender immediately. Please note
that
> > > messages
> > > sent or received by the Tessella e-mail system may be
monitored
> > and
> > > stored
> > > in an information retrieval system.
> > >
> >
> >
> >
> >
> > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> >
> >
>
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
[attachment "drools-persistence-test.zip" deleted by Alan
Gairey/Tessella]
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm