On 09/07/2011 23:59, Mikael Lönneberg wrote: > Hi, > > In trying to fix JBRULES-2730 and JBRULES-3063, I noticed that fixing > this issue will actually break MiscTest#testRuleReplacement. > So should this test case be rewritten to not allow rule replacement, > or are there circumstances where rule replacements are allowed and if > that is the case what are those circumstances? Rule replacement is allowed and an important part of a dynamic rule engine. I believe what we do is disallow it from the same resource (should double check that) i.e. a drl that repeats the rule twice is an error. If you load a later resource it will overwrite the previous.

> > ConsequenceOffsetTest.testConsequenceOffset also fails due to loading > two resource files with the same package and rule name defined in the > different files. > Sounds like a bug, can you update some stronger tests and fix? Mark > > Kind regards > > Mikael Lonneberg - gwendo > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev

On 10/07/2011 00:23, Mark Proctor wrote: On 10/07/2011 00:20, Mark Proctor wrote: On 09/07/2011 23:59, Mikael Lönneberg wrote: Hi, In trying to fix JBRULES-2730 and JBRULES-3063, I noticed that fixing this issue will actually break MiscTest#testRuleReplacement. So should this test case be rewritten to not allow rule replacement, or are there circumstances where rule replacements are allowed and if that is the case what are those circumstances? Rule replacement is allowed and an important part of a dynamic rule engine. I believe what we do is disallow it from the same resource (should double check that) i.e. a drl that repeats the rule twice is an error. If you load a later resource it will overwrite the previous. Thinking about this some more. We should probably add a "getWarnings" as well as getErrors. Rule overwriting would come with a warning. We might even find a way build warning filters, a composite set of warnings to fail on, but user defineable. If you want to work on a separate jira for this? 1) add warnings list to packagebuilder 2) add hasWarnings and getWarnings, in mirror of errors. 3) allow hashWarnings and getWarnings to take positive/negative warnings. i.e. ignore duplicate resource (hasWarnings would return false), report duplicate file (is returned in list). This should be some sort of chainable or compositable filter, with sane defaults.

For us to include this it will need to be well unit tested and ideally report other types of warnings too... Ideas on other types of warnings (note this is different to verification and analysis) Mark ConsequenceOffsetTest.testConsequenceOffset also fails due to loading two resource files with the same package and rule name defined in the different files. Sounds like a bug, can you update some stronger tests and fix? Mark Kind regards Mikael Lonneberg - gwendo _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev