If I'm not too Sauvignon-Blanced-out at the moment: the error message reads
"cannot be cast to a org.drools.common.EventFactHandle".
But the WM(EntryPoint) could very well do a getFactHandle( Object x ), which
would succeed and give it the equivalent of the bound variable's
full-fledged event.
So, in addition to (order to be decided) testing for Date/long/event, just
one more try with getFactHandle()... ?
Cheers!
-W
2010/8/13 Edson Tirelli <tirelli(a)post.com>
Hi Wolfgang,
I will explain why it happens and we can discuss how to improve that (at
least improving the error message).
All temporal operators work when used against either an event, a date
attribute or a long attribute (interpreted as a timestamp).
In your example:
Wrapper( $eventA : foo )
$eventB : Bar( this after[0ms,1h] $eventA )
The engine has no idea that $eventA is an event in the working memory.
From the engine's point of view, it is just a "foo" attribute from the
Wrapper fact. So it checks if event A is a Date (nope), a long (nope) and
finally tries to use it as an event raising the exception you see.
On your last example:
$eventA : Foo( this == $foo )
$eventA is an event in the working memory with all the internal
metadata required to handle events. So, in this case, the engine knows how
to deal with it.
Suggestions on how to improve that are welcome.
Edson
2010/8/13 Wolfgang Laun <wolfgang.laun(a)gmail.com>
> According to the Fusion manual, "after" is used like this:
>
> $eventA : Foo(...)
> $eventB : Bar( this after[0ms,1h] $eventA )
>
> provided Foo and Bar have @role(event).
>
> This works.
>
> But, given a class Wrapper( Foo foo ), the pattern combination
> Wrapper( $eventA : foo )
> $eventB : Bar( this after[0ms,1h] $eventA )
> results in a class cast exception at runtime, telling me that a Foo cannot
> be cast to a org.drools.common.EventFactHandle.
>
> Working around this by doing
> Wrapper( $foo: foo )
> $eventA : Foo( this == $foo )
> $eventB : Bar( this after[0ms,1h] $eventA )
>
> solves the problem, but is this really necessary and intentional? (The
> documentation doesn't even hint at such a restriction.)
>
> -W
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users