2:31 p.m.
Wolfgang, thanks much. Helps me understand what's going on under the hood a
little better.
I'm having a similar issue with the next higher container. I have say,
PathElements which contain a collection of Ports. Same problem as before -
if one Port goes down then the PathElement goes down. I can't seem to
express it properly in DRL
The only thing that comes to me is:
rule "pe down"
when
// pe is active
$pe : PathElement(state == State.UP )
// and any one of the ports are down
Port ( state == State.DOWN ) from $pe.ports
then
System.out.println(" setting pe down" + $pe );
modify($pe) {
setState( State.DOWN);
}
end
However, like my other naive attempts, it is not firing after the
Notification is inserted into WM. I tried many variations using a 'collect'
clause, etc to no avail. Any additional insight would be greatly
appreciated.
BTW, once i get a handle on the one-to-many associations I promise I'll
stop :-)
On Mon, Apr 2, 2012 at 11:47 PM, Wolfgang Laun <wolfgang.laun(a)gmail.com>wrote:
See inline.
On 02/04/2012, Joe Zendle <jzendle(a)zentechinc.net> wrote:
>
>
> Here are my rules:
>
> rule "card going down"
> when
// There is a Card in state UP and...
> $card : Card($name : name , state == State.UP)
// a matching notification to DOWN
> $notif : Notification( id == $name, type ==
NotificationType.CARD ,
> state == State.DOWN )
> then
> System.out.println(" got notification for card down " + $card );
> modify($card) {
> setState(State.DOWN);
> }
> retract($notif);
> end
>
> // is the following rule correct??
No.
>
> rule "port going down"
> when
// There is a Port in State UP and...
> $port : Port($name : name , state == State.UP, $card : card)
// ...take its Card and if this is DOWN
> Card ( state == State.DOWN) from $card
> then
> System.out.println(" port down because card is down port: " +
$port +
> " card: " + $card );
> modify($port) {
> setState(State.DOWN);
> }
The difference between these two rules is that the first one is triggered
by
a change in WM - the emergence of a matching Notification. The second,
however, is evaluated when the Port enters WM, presumably with its
Card in working order. Subsequently, Port doesn't change and so evaluation
is never retried.
Two correct versions:
when
$card : Card( state == State.DOWN )
$port : Port($name : name , state == State.UP, card == $card)
then
when
$port : Port($name : name , state == State.UP, $card: card )
Card( this == $card, state == State.DOWN )
then
Or, assuming that Port must follow Card, for going UP and DOWN:
when
$card : Card( $stateCard: state )
$port : Port($name : name , state != $stateCard, card == $card)
then
modify($port) {
setState($stateCard)
}
>
> end
>
> Here is the test case in a nutshell:
>
> Port port1 = new Port();
> Port port2 = new Port();
> port1.setName("port1");
> port2.setName("port2");
>
> Card card1 = new Card();
> card1.setName("port1 card1")
> port1.setCard(card1);
> // stateful session
> ksession.insert(port1);
> ksession.insert(port2);
> ksession.insert(card1);
>
> System.out.println(" firing rules");
> new Thread(new Runnable() {
> public void run() {
> ksession.fireUntilHalt();
> }
> }).start();
>
> System.out.println("*** injecting notification down");
> Notification notif = new Notification();
> notif.setType(NotificationType.CARD);
> notif.setState(State.DOWN);
> notif.setId("port1 card1");
> FactHandle notifHandle = ksession.insert(notif);
>
>
> ksession.halt();
> ksession.dispose()
>
>
> I would expect the card down notification to cause the port to do down by
> the second rule above but it does not fire.
>
> Here is output
>
> card1: Card [state=UP, name=port1 card1,
> ne=org.plugtree.examples.model.NE@1e2670b]
> OBJECT ASSERTED value:Port [state=UP, name=port1, card=Card [state=UP,
> name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b]] factId: 1
> OBJECT ASSERTED value:Port [state=UP, name=port2, card=Card [state=UP,
> name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b]] factId: 3
> OBJECT ASSERTED value:Card [state=UP, name=port1 card1,
> ne=org.plugtree.examples.model.NE@1e2670b] factId: 5
> firing rules
> 3
> *** injecting notification down
> ACTIVATION CREATED rule:card going down activationId:card going down [6,
5]
> declarations: $name=port1 card1(5);
> $notif=org.plugtree.examples.model.Notification@4a9a7d(6); $card=Card
> [state=UP, name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b
](5)
> OBJECT ASSERTED
value:org.plugtree.examples.model.Notification@4a9a7dfactId:
> 6
> BEFORE ACTIVATION FIRED rule:card going down activationId:card going down
> [6, 5] declarations: $name=port1 card1(5);
> $notif=org.plugtree.examples.model.Notification@4a9a7d(6); $card=Card
> [state=UP, name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b
](5)
> got notification for card down Card [state=UP, name=port1 card1,
> ne=org.plugtree.examples.model.NE@1e2670b]
> OBJECT MODIFIED value:Card [state=DOWN, name=port1 card1,
> ne=org.plugtree.examples.model.NE@1e2670b] factId: 5
> OBJECT RETRACTED
> value:org.plugtree.examples.model.Notification@4a9a7dfactId: 6
> AFTER ACTIVATION FIRED rule:card going down activationId:card going down
> [-1, 5] declarations: $name=port1 card1(5); $card=Card [state=DOWN,
> name=port1 card1, ne=org.plugtree.examples.model.NE@1e2670b](5)
>
>
>
> Is the second rule written incorrectly? or do i have a gap in my
> expectations of how the engine should work (or both)
>
> Thanks in advance,
>
> Joe.
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users