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.