We are in the process of converting from 3.0.4 to 3.1.0-M1 and having problems building rules with a dsl that built in 3.0.4 with no problems.

We are getting rule compilation errors reporting:

        String literal is not properly closed by a double-quote

The problem was isolated to the following, a dsl mapping that works in 3.0.4

        [then]Log : {level} , {message}=logUtil.log ( {level}  , "{message}\n" );

We had to change it to the following to get past the compile error.

        [then]Log : {level} , {message}=logUtil.log ( {level}  , "{message}");

Tried to get the lf in various ways but no luck. Only way would be to modify every message and add a LF

[then]Log : {level} , {message}=logUtil.log ( {level}  , "{message}" + "\n");  -- no good got same error.

This was not easy to find either. The error message above was not of much use.

Regards,

Tom G

Tom - there was some MAJOR re-work for 3.1m1 - could you put this in a JIRA - that example, perhaps with the test code, but at least the example.
Its probably some regex-foo stuffing up and choking on the \n, no doubt.  That would be great.

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

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 !

Hi,

OK, I'm determined to make an effort to understand what goes on under the hood of Rules and related sub-projects (BRMS for example) and potentially, one day contribute. So I eagerly added the SVN plug-in to Eclipse and set off getting the latest source from http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/. Could a kindly developer please confirm, deny or advise whether M2_REPO should point to a local copy of http://repository.jboss.com/maven2 (if I want to run and build from Eclipse rather than ANT)?

With kind regards,

Mike

M2_REPO \ use of Maven2 repository?

Hi,

OK, I'm determined to make an effort to understand what goes on under the hood of Rules and related sub-projects (BRMS for example) and potentially, one day contribute. So I eagerly added the SVN plug-in to Eclipse and set off getting the latest source from http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/. Could a kindly developer please confirm, deny or advise whether M2_REPO should point to a local copy of http://repository.jboss.com/maven2 (if I want to run and build from Eclipse rather than ANT)?

With kind regards,

Mike

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev