[rules-dev] Drools 3.1.0-M1 rules build 3.0.4 compatibility problems with eval statements

[Michael Neale]

Hi Tom - its great you are trying this out - once again - coudl you attach
enough to repoduce this to a JIRA? It will get added to the integration
tests.

There is no fundamental reason why you can't cast like that at all, its
certainly not a design constraint, just - SHOCK - a bug ! Say it isn't so !

On 3/2/07, Tom Gonzalez <tomgon at nortel.com> wrote:
>
>  We are in the process of converting from 3.0.4 to 3.1.0-M1 and having
> problems building rules that have eval statements in them that build in
> 3.0.4 with no problems.
>
> We are getting rules build errors as follows:
>
>      [java] Feb 28, 2007 5:55:29 PM
> com.nortel.connect.rbuilder.RulePackager build
>      [java] INFO: ============== Start build RulePackage: [engrules.mss]
> =========
>      [java] Feb 28, 2007 5:55:29 PM
> com.nortel.connect.rbuilder.RulePackage addRulesFromDrlFile
>      [java] INFO:       adding Rules from: MG15000Rules.drl (with
> associated DSL)
>      [java] Feb 28, 2007 5:55:29 PM
> com.nortel.connect.rbuilder.RulePackage addRulesFromDrlFile
>      [java] INFO:       parsed rules using dsl
>     * **[java] org.drools.RuntimeDroolsException: unable to find the
> function ','*
>      [java]     at
> org.drools.semantics.java.StaticMethodFunctionResolver.resolveFunction(
> StaticMethodFunctionResolver.java:9)
>
>      [java]     at org.drools.semantics.java.FunctionFixer.fix(
> FunctionFixer.java:132)
>      [java]     at org.drools.semantics.java.FunctionFixer.fix(
> FunctionFixer.java:103)
>      [java]     at org.drools.semantics.java.FunctionFixer.fix(
> FunctionFixer.java:66)
>      [java]     at org.drools.semantics.java.builder.EvalBuilder.build(
> EvalBuilder.java:78)
>      [java]     at
> org.drools.semantics.java.builder.GroupElementBuilder.build(
> GroupElementBuilder.java:63)
>      [java]     at
> org.drools.semantics.java.builder.GroupElementBuilder.build(
> GroupElementBuilder.java:63)
>      [java]     at org.drools.semantics.java.RuleBuilder.build(
> RuleBuilder.java:178)
>      [java]     at org.drools.compiler.PackageBuilder.addRule(
> PackageBuilder.java:381)
>      [java]     at org.drools.compiler.PackageBuilder.addPackage(
> PackageBuilder.java:219)
>      [java]     at
> com.nortel.connect.rbuilder.RulePackage.addRulesFromDrlFile(
> RulePackage.java:229)
>      [java]     at com.nortel.connect.rbuilder.RulePackager.build(
> RulePackager.java:206)
>      [java]     at com.nortel.connect.rbuilder.RulePackager.buildAll(
> RulePackager.java:142)
>      [java]     at com.nortel.connect.rbuilder.RulePackager.main(
> RulePackager.java:92)
>      [java] Feb 28, 2007 5:55:30 PM
> com.nortel.connect.rbuilder.RulePackage addRulesFromDrlFile
>
> We have a number of rules with eval's in them such as:
>
> eval( !(checkVspToInstanceRatio( (Integer)$vsp3ocount,
> (Integer)$vsp4ecount, (Integer)$vsp3count, (Integer)$nstacount)) );
>
> eval ( !(strInStr((String)$shelfsn,(String)$netwksn))
>
> eval( !(checkDlepNumber( (Integer)$dlepkey, (Integer)$nstakey)) ||
> !(isEvenInteger((Integer)$nstakey))
>
> The parser has issue with the cast syntax in the eval removing the cast
> (like (Integer) ) cleans up the paser issue however this is not a feasible
> solution. Casting is required in some cases with out adding a good bit of
> extra work.
>
> Can you restore the support we previously had for casting with in an eval
> and retain the flexibility of using casts when needed?
>
> Thanks,
>
> Regards,
>
> Tom G
>
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070302/1f534fc7/attachment.html