[rules-users] before/after behavior for negative pattern

[Wolfgang Laun]

Both look like a bug to me. Even if RawEvent is an (abstract) base class,
the "unable to resolve method" should not occur. (Are you using dialect
MVEL?)

Are you using a separate thread running kSession.fireUntilHalt()? There was
an
alert indicating a race condition in 5.4.0.

Can you post a reduced set of Java and DRL code reproducing both errors?

-W


On 1 September 2012 18:41, Rob21 <rob.perrez at gmail.com> wrote:

> Actually i meant that the first rule worked for every beginning of
> scenario,
> except the first scenario if the first event is a RawEvent. The second rule
> doesn't work at all and gives me this :
>
> Thread [main] (Suspended (exception NullPointerException))
>
>
> BeforeEvaluatorDefinition$BeforeEvaluator.evaluateCachedLeft(InternalWorkingMemory,
> VariableRestriction$VariableContextEntry, Object) line: 343
>         EvaluatorConstraint.isAllowedCachedLeft(ContextEntry,
> InternalFactHandle)
> line: 67
>         DoubleBetaConstraints.isAllowedCachedLeft(ContextEntry[],
> InternalFactHandle) line: 168
>         NotNode.assertLeftTuple(LeftTuple, PropagationContext,
> InternalWorkingMemory) line: 80
>
> SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(PropagationContext,
> InternalWorkingMemory, LeftTuple) line: 196
>
>
> SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(InternalFactHandle,
> PropagationContext, InternalWorkingMemory, boolean, LeftInputAdapterNode)
> line: 145
>         LeftInputAdapterNode.assertObject(InternalFactHandle,
> PropagationContext,
> InternalWorkingMemory) line: 154
>
> CompositeObjectSinkAdapter.doPropagateAssertObject(InternalFactHandle,
> PropagationContext, InternalWorkingMemory, ObjectSink) line: 497
>
> CompositeObjectSinkAdapter.propagateAssertObject(InternalFactHandle,
> PropagationContext, InternalWorkingMemory) line: 382
>         ObjectTypeNode.assertObject(InternalFactHandle, PropagationContext,
> InternalWorkingMemory) line: 235
>         EntryPointNode.assertObject(InternalFactHandle, PropagationContext,
> ObjectTypeConf, InternalWorkingMemory) line: 240
>         NamedEntryPoint.insert(InternalFactHandle, Object, Rule,
> Activation,
> ObjectTypeConf) line: 337
>         NamedEntryPoint.insert(Object, boolean, boolean, Rule, Activation)
> line:
> 298
>         ReteooStatefulSession(AbstractWorkingMemory).insert(Object,
> boolean,
> boolean, Rule, Activation) line: 888
>         ReteooStatefulSession(AbstractWorkingMemory).insert(Object) line:
> 847
>         StatefulKnowledgeSessionImpl.insert(Object) line: 269
>         DroolsTest.sendEvents(String, StatefulKnowledgeSession) line: 85
>         DroolsTest.main(String[]) line: 62
>
> About "this != $start", i tried that also as the documentation contains a
> similar example with heartbeats.
> Still for this rule :
> rule "Detect it"
>         when
>                 $start : RawEvent()
>                 not RawEvent(this != $start, id == $start.id, $start
> after[0s, 90s] this)
>         then
>                 System.out.println($start);
> end
> The application terminates and Drools answers this :
> Unable to Analyse Expression this != $start && after0.evaluate( $start,
> this
> ):
> [Error: unable to resolve method using strict-mode:
> com.sample.RawEvent.after0()]
> [Near : {... this != $start && after0.evaluate( $start, this ....}]
>              ^ : [Rule name='Detect it']
>
> java.lang.IllegalArgumentException: Could not parse knowledge.
>         at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:109)
>         at com.sample.DroolsTest.main(DroolsTest.java:54)
>
> Which I don't understand
>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/before-after-behavior-for-negative-pattern-tp4019497p4019499.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120901/a7ef4aff/attachment.html