[rules-users] need design suggestion

[Joe Zendle]

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 at gmail.com>wrote:

> See inline.
>
> On 02/04/2012, Joe Zendle <jzendle at 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 at 1e2670b]
> > OBJECT ASSERTED value:Port [state=UP, name=port1, card=Card [state=UP,
> > name=port1 card1, ne=org.plugtree.examples.model.NE at 1e2670b]] factId: 1
> > OBJECT ASSERTED value:Port [state=UP, name=port2, card=Card [state=UP,
> > name=port1 card1, ne=org.plugtree.examples.model.NE at 1e2670b]] factId: 3
> > OBJECT ASSERTED value:Card [state=UP, name=port1 card1,
> > ne=org.plugtree.examples.model.NE at 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 at 4a9a7d(6); $card=Card
> > [state=UP, name=port1 card1, ne=org.plugtree.examples.model.NE at 1e2670b
> ](5)
> > OBJECT ASSERTED
> value:org.plugtree.examples.model.Notification at 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 at 4a9a7d(6); $card=Card
> > [state=UP, name=port1 card1, ne=org.plugtree.examples.model.NE at 1e2670b
> ](5)
> >   got notification for card down Card [state=UP, name=port1 card1,
> > ne=org.plugtree.examples.model.NE at 1e2670b]
> > OBJECT MODIFIED value:Card [state=DOWN, name=port1 card1,
> > ne=org.plugtree.examples.model.NE at 1e2670b] factId: 5
> > OBJECT RETRACTED
> > value:org.plugtree.examples.model.Notification at 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 at 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 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/20120403/47803dbb/attachment.html