Man... you made my day! Such a Dumb! Thats true, first is inserted the Task and after that the Param is added. Im wondering if I update the fact, all the rules fired before updating it would fire again? Or just the rules which conditions are changed?
I guess: R1 When T T.X Then ... R2 When T T.Y Then ... R3 When T Then ... If T is asserted but not T.X neither T.Y, R3 is fired. If after this, T.X is asserted (I mean updating T), I guess R3 will not be fired again... and if T is updated again but retracting T.X, then R1 should perform rollback of the RHS clausure... is this the actual behavior? -----Mensaje original----- De: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] En nombre de Wolfgang Laun Enviado el: dimarts, 10 / novembre / 2009 12:41 Para: Rules Users List Asunto: Re: [rules-users] Inconsistent behavior between LHS and RHS ... There are a couple of scenarios that might produce this effect: One is: // session is running ! Task t = new Task(); session.insert ( t ); t.getTechnicalParams().add(...) Can you exclude this or a similar scenario, where Parameters are added to an existing Task() fact, without update() of the fact? -W On Tue, Nov 10, 2009 at 9:22 AM, Javier Vera Gomez <javier.v...@andorratelecom.ad> wrote: > Thanks for answering, > > Further detail: > The actual output is the rule is fired (ie, the param is not found) and then > the param is printed out. So, in fact, the param does exists. > > The Task is created as usual, nothing special here (insert (new Task...) > > Code fragment from Task.java: > > public String getParameter(String name){ > for (Parameter param : getTechnicalParams()) { > if( name.equals(param.getName()) ) { > return param.getValue(); > } > } > return null; > } > > @XmlElement(name="parameter",nillable = true) > �...@xmlelementwrapper(name="technicalParams") > protected List<Parameter> technicalParams; > > public List<Parameter> getTechnicalParams() { > if (technicalParams == null) { > technicalParams = new ArrayList<Parameter>(); > } > return this.technicalParams; > } > > > It is important to note that in other flows of similar rules this is working > perfect... I know I have not giving so much input but I do not know what else > could provide. > > Any clues ? > > -----Mensaje original----- > De: rules-users-boun...@lists.jboss.org > [mailto:rules-users-boun...@lists.jboss.org] En nombre de Wolfgang Laun > Enviado el: dilluns, 9 / novembre / 2009 13:56 > Para: Rules Users List > Asunto: Re: [rules-users] Inconsistent behavior between LHS and RHS ... > > It's difficult to assess this case without the code from Task.java, > especially mehtods getParameter(), getTechnicalParams(); the code used > to create the Task fact, and the actual output. > -W > > 2009/11/9 Javier Vera Gomez <javier.v...@andorratelecom.ad>: >> Hi, >> >> I've been using drools 4.07 for a while. I have found a weird case. It seems >> that when evaluating the LHS some fact is true but the RHS probes it wasn't >> actually true. >> >> The example code is at the end. It is very weird to me I have no clue about >> how to solve this or what could be happening! >> >> rule "A-Rule" >> no-loop true >> ruleflow-group "validate-task" >> salience -9999999 >> when >> >$task : Task( type == "Creacio_Profile_Radius" ) >> >eval($task.getParameter("PRIMARYDNS")==null) >> then >> >System.out.println(">>>DBGPar0: >> "+$task.getTechnicalParams().get(0).getName()); >> >System.out.println(">>>DBGPar1: >> "+$task.getTechnicalParams().get(1).getName()); >> >System.out.println("Getparam PRIMARYDNS: >> "+$task.getParameter("PRIMARYDNS")); >> end >> >> >> further explanation: >> >> The Task class has a List<Parameter> technicalParams, originally the eval >> part was: >> not(Parameter (name=="PRIMARYDNS") from $task.technicalParams()) >> >> it didn't work and I coded this "getParameter" method just to make some >> tests. So, it seems the collection appears "empty" to the LHS but in fact it >> isnt! >> >> any clue? >> >> thanks a lot, >> >> Javier >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
