3:21 a.m.
Hi all,
Triggered by a post on this forum, I decided to try a testcase
implementation of Drool Verifiier.
I manage to write some code that does not produce any errors at runtime,
which is good. Unfortunately, it doesn't produce any errors/warnings/notes
on my rulefile either, which isn't good.
The drl file consists of some duplicate rules, and since the file is only
part of a ruleset, there might be some gaps as well.
I pasted the java-code below. Does anyone see where I am going wrong?
Thanks in advance!
Regards,
Frank
VerifierBuilder vBuilder =
VerifierBuilderFactory.newVerifierBuilder();
Verifier verifier = vBuilder.newVerifier();
String ruleText =
"C:\\Users\\Frank\\Documents\\DroolsWorkSpaces\\EmpiricalExperiments\\Financial
Rules\\src\\main\\rules\\clearancerules.drl";
verifier.addResourcesToVerify( ResourceFactory.newReaderResource(
new StringReader( ruleText ) ), ResourceType.DRL );
verifier.fireAnalysis();
VerifierReport result = verifier.getResult();
for(VerifierMessageBase base: result.getBySeverity(
Severity.ERROR ) ){
System.out.println( base );
}
for(VerifierMessageBase base: result.getBySeverity(
Severity.WARNING ) ){
System.out.println( base );
}
for(VerifierMessageBase base: result.getBySeverity( Severity.NOTE )
){
System.out.println( base );
}
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
4:58 a.m.
Try a rule with an empty consequence. (rule x when Object() then end).
The .DRL file must compile for the Verifier to do its task.
Duplicate rules (rule names) do not compile.
"Gaps" is not something a verifier would detect. It does not try to
"understand" your rules. What do you expect?
-W
On 15 March 2011 09:21, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
Hi all,
Triggered by a post on this forum, I decided to try a testcase
implementation of Drool Verifiier.
I manage to write some code that does not produce any errors at runtime,
which is good. Unfortunately, it doesn't produce any errors/warnings/notes
on my rulefile either, which isn't good.
The drl file consists of some duplicate rules, and since the file is only
part of a ruleset, there might be some gaps as well.
I pasted the java-code below. Does anyone see where I am going wrong?
Thanks in advance!
Regards,
Frank
VerifierBuilder vBuilder =
VerifierBuilderFactory.newVerifierBuilder();
Verifier verifier = vBuilder.newVerifier();
String ruleText =
"C:\\Users\\Frank\\Documents\\DroolsWorkSpaces\\EmpiricalExperiments\\Financial
Rules\\src\\main\\rules\\clearancerules.drl";
verifier.addResourcesToVerify(
ResourceFactory.newReaderResource(
new StringReader( ruleText ) ), ResourceType.DRL );
verifier.fireAnalysis();
VerifierReport result = verifier.getResult();
for(VerifierMessageBase base: result.getBySeverity(
Severity.ERROR ) ){
System.out.println( base );
}
for(VerifierMessageBase base: result.getBySeverity(
Severity.WARNING ) ){
System.out.println( base );
}
for(VerifierMessageBase base: result.getBySeverity(
Severity.NOTE )
){
System.out.println( base );
}
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:07 a.m.
Hi Frank and Wolfgang,
Looks right. Are you using the latest codes or 5.2.0.M1? The latest codes in git are not
working properly.
If you get the same result with any of the the Drools release jars please open a Jira and
I will take a look.
"Gaps" is not something a verifier would detect. It does
not try to
"understand" your rules. What do you expect?
The verifier can actually find some gaps from rule sets. For example uncovered checks for
number values.
If you have
Person( age <18 )
it gives a warning that you might want to cover Person( age >= 18 ).
Toni Rikkola
On Mar 15, 2011, at 11:58 AM, Wolfgang Laun wrote:
> Try a rule with an empty consequence. (rule x when Object() then end).
>
> The .DRL file must compile for the Verifier to do its task.
> Duplicate rules (rule names) do not compile.
>
"Gaps" is not something a verifier would detect. It does
not try to
"understand" your rules. What do you expect?
>
> -W
>
>
> On 15 March 2011 09:21, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
> Hi all,
>
> Triggered by a post on this forum, I decided to try a testcase
> implementation of Drool Verifiier.
>
> I manage to write some code that does not produce any errors at runtime,
> which is good. Unfortunately, it doesn't produce any errors/warnings/notes
> on my rulefile either, which isn't good.
>
> The drl file consists of some duplicate rules, and since the file is only
> part of a ruleset, there might be some gaps as well.
>
> I pasted the java-code below. Does anyone see where I am going wrong?
>
> Thanks in advance!
>
> Regards,
> Frank
>
> VerifierBuilder vBuilder =
> VerifierBuilderFactory.newVerifierBuilder();
>
> Verifier verifier = vBuilder.newVerifier();
>
> String ruleText =
> "C:\\Users\\Frank\\Documents\\DroolsWorkSpaces\\EmpiricalExperiments\\Financial
> Rules\\src\\main\\rules\\clearancerules.drl";
> verifier.addResourcesToVerify( ResourceFactory.newReaderResource(
> new StringReader( ruleText ) ), ResourceType.DRL );
>
> verifier.fireAnalysis();
>
> VerifierReport result = verifier.getResult();
>
> for(VerifierMessageBase base: result.getBySeverity(
> Severity.ERROR ) ){
> System.out.println( base );
> }
> for(VerifierMessageBase base: result.getBySeverity(
> Severity.WARNING ) ){
> System.out.println( base );
> }
> for(VerifierMessageBase base: result.getBySeverity( Severity.NOTE )
> ){
> System.out.println( base );
> }
>
> --
> View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
5:39 a.m.
2011/3/15 Toni Rikkola <toni.rikkola(a)gmail.com>
The verifier can actually find some gaps from rule sets. For example
uncovered checks for number values.
If you have
Person( age <18 )
it gives a warning that you might want to cover Person( age >= 18 ).
I'd say that such a warning may not be very useful because
- in many cases you may not be interested in the "other" values at all,
- in some cases 18, 19,... is handled with Person( age < 50 ) with low
salience (not recommended!),
- in many (other) cases you use a (low salience) "catch all" rule to
handle facts not selected by 1st order rules,
Moreover, I'm thinking of using additional rules with Verifier, with one of
the primary targets being "magic numbers".
But Verifier is a fine achievement, and the confiugration is here to get you
what you want!
-W
Toni Rikkola
6:10 a.m.
Yes it can often be ignored and we need some configuration to silence the unwanted
warnings. The current way is best for use cases like the decision table verification in
Guvnor.
Age is a good example. Person's age can't be less than 0 or more than 120. The top
number is difficult. 120 is pretty safe, but usually you should be suspicious from ~90.
So in the configurations you could set:
Person.age 0-90 => check that they are covered
Person.age 90-120 => check them, but make a notification
You can of course do this today with custom verification rules. Just use a clean verifier
base and add your own verifier rules.
Toni
On Mar 15, 2011, at 12:39 PM, Wolfgang Laun wrote:
2011/3/15 Toni Rikkola <toni.rikkola(a)gmail.com>
The verifier can actually find some gaps from rule sets. For example uncovered checks for
number values.
If you have
Person( age <18 )
it gives a warning that you might want to cover Person( age >= 18 ).
I'd say that such a warning may not be very useful because
- in many cases you may not be interested in the "other" values at all,
- in some cases 18, 19,... is handled with Person( age < 50 ) with low salience
(not recommended!),
- in many (other) cases you use a (low salience) "catch all" rule to handle
facts not selected by 1st order rules,
Moreover, I'm thinking of using additional rules with Verifier, with one of the
primary targets being "magic numbers".
But Verifier is a fine achievement, and the confiugration is here to get you what you
want!
-W
Toni Rikkola
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:02 a.m.
Hi Toni and Wolfgang,
Thanks for your replies.
First, to clarify my self, with "duplicate rules", I actually meant "rules
that are exactlly the same, but with other names". Moreover, I inserted the
verification just before rule execution, and execution runs fine. So, there
shouldn't be a compile error.
Removing the "then" part of a rule does not make any difference. It still
runs, but doesn't return any notes/warnings/errors in the ruleset.
Toni, I am not using one of the "M" versions. Drools verifier is version
5.1.0.
As a general remark, I definitely agree that "gap analysis" often comes up
with some very unuseful information. I usually call those uncovered areas,
"women with beards" or "experienced juniors". However, there always
might be
valuable information in there. Besides, the question whether this
information is valuable or not, doesn't matter, it just doesn't show and it
should.
Regards,
Frank
Toni Rikkola-2 wrote:
Yes it can often be ignored and we need some configuration to silence the
unwanted warnings. The current way is best for use cases like the decision
table verification in Guvnor.
Age is a good example. Person's age can't be less than 0 or more than 120.
The top number is difficult. 120 is pretty safe, but usually you should be
suspicious from ~90.
So in the configurations you could set:
Person.age 0-90 => check that they are covered
Person.age 90-120 => check them, but make a notification
You can of course do this today with custom verification rules. Just use a
clean verifier base and add your own verifier rules.
Toni
On Mar 15, 2011, at 12:39 PM, Wolfgang Laun wrote:
> 2011/3/15 Toni Rikkola &lt;toni.rikkola(a)gmail.com&gt;
>
> The verifier can actually find some gaps from rule sets. For example
> uncovered checks for number values.
> If you have
> Person( age <18 )
> it gives a warning that you might want to cover Person( age >= 18 ).
>
>
> I'd say that such a warning may not be very useful because
> - in many cases you may not be interested in the "other" values at
> all,
> - in some cases 18, 19,... is handled with Person( age < 50 ) with low
> salience (not recommended!),
> - in many (other) cases you use a (low salience) "catch all" rule to
> handle facts not selected by 1st order rules,
>
> Moreover, I'm thinking of using additional rules with Verifier, with one
> of the primary targets being "magic numbers".
>
> But Verifier is a fine achievement, and the confiugration is here to get
> you what you want!
>
> -W
>
>
> Toni Rikkola
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
4:55 a.m.
It's really worthwhile to add a DRL compile run before you let the verifier
do its work.
-W
On 16 March 2011 10:02, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
Hi Toni and Wolfgang,
Thanks for your replies.
First, to clarify my self, with "duplicate rules", I actually meant
"rules
that are exactlly the same, but with other names". Moreover, I inserted the
verification just before rule execution, and execution runs fine. So, there
shouldn't be a compile error.
Removing the "then" part of a rule does not make any difference. It still
runs, but doesn't return any notes/warnings/errors in the ruleset.
Toni, I am not using one of the "M" versions. Drools verifier is version
5.1.0.
As a general remark, I definitely agree that "gap analysis" often comes up
with some very unuseful information. I usually call those uncovered areas,
"women with beards" or "experienced juniors". However, there always
might
be
valuable information in there. Besides, the question whether this
information is valuable or not, doesn't matter, it just doesn't show and it
should.
Regards,
Frank
Toni Rikkola-2 wrote:
>
> Yes it can often be ignored and we need some configuration to silence the
> unwanted warnings. The current way is best for use cases like the
decision
> table verification in Guvnor.
>
> Age is a good example. Person's age can't be less than 0 or more than
120.
> The top number is difficult. 120 is pretty safe, but usually you should
be
> suspicious from ~90.
> So in the configurations you could set:
> Person.age 0-90 => check that they are covered
> Person.age 90-120 => check them, but make a notification
>
> You can of course do this today with custom verification rules. Just use
a
> clean verifier base and add your own verifier rules.
>
> Toni
>
> On Mar 15, 2011, at 12:39 PM, Wolfgang Laun wrote:
>
>> 2011/3/15 Toni Rikkola &lt;toni.rikkola(a)gmail.com&gt;
>>
>> The verifier can actually find some gaps from rule sets. For example
>> uncovered checks for number values.
>> If you have
>> Person( age <18 )
>> it gives a warning that you might want to cover Person( age >= 18 ).
>>
>>
>> I'd say that such a warning may not be very useful because
>> - in many cases you may not be interested in the "other" values at
>> all,
>> - in some cases 18, 19,... is handled with Person( age < 50 ) with
low
>> salience (not recommended!),
>> - in many (other) cases you use a (low salience) "catch all" rule
to
>> handle facts not selected by 1st order rules,
>>
>> Moreover, I'm thinking of using additional rules with Verifier, with one
>> of the primary targets being "magic numbers".
>>
>> But Verifier is a fine achievement, and the confiugration is here to get
>> you what you want!
>>
>> -W
>>
>>
>> Toni Rikkola
>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:28 a.m.
I've just realized that the code you posted does not include checking for
errors during the verifier builds.
List<VerifierError> errors = verifier.getErrors();
if( errors.size() > 0 ){
printStream.println( "### Verifier errors ###" );
for( VerifierError error: errors ){
printStream.println( error.getMessage() );
}
} else {
VerifierReport result = verifier.getResult();
// here we can obtain Verifier results...
}
On 16 March 2011 10:02, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
Hi Toni and Wolfgang,
Thanks for your replies.
First, to clarify my self, with "duplicate rules", I actually meant
"rules
that are exactlly the same, but with other names". Moreover, I inserted the
verification just before rule execution, and execution runs fine. So, there
shouldn't be a compile error.
Removing the "then" part of a rule does not make any difference. It still
runs, but doesn't return any notes/warnings/errors in the ruleset.
Toni, I am not using one of the "M" versions. Drools verifier is version
5.1.0.
As a general remark, I definitely agree that "gap analysis" often comes up
with some very unuseful information. I usually call those uncovered areas,
"women with beards" or "experienced juniors". However, there always
might
be
valuable information in there. Besides, the question whether this
information is valuable or not, doesn't matter, it just doesn't show and it
should.
Regards,
Frank
Toni Rikkola-2 wrote:
>
> Yes it can often be ignored and we need some configuration to silence the
> unwanted warnings. The current way is best for use cases like the
decision
> table verification in Guvnor.
>
> Age is a good example. Person's age can't be less than 0 or more than
120.
> The top number is difficult. 120 is pretty safe, but usually you should
be
> suspicious from ~90.
> So in the configurations you could set:
> Person.age 0-90 => check that they are covered
> Person.age 90-120 => check them, but make a notification
>
> You can of course do this today with custom verification rules. Just use
a
> clean verifier base and add your own verifier rules.
>
> Toni
>
> On Mar 15, 2011, at 12:39 PM, Wolfgang Laun wrote:
>
>> 2011/3/15 Toni Rikkola &lt;toni.rikkola(a)gmail.com&gt;
>>
>> The verifier can actually find some gaps from rule sets. For example
>> uncovered checks for number values.
>> If you have
>> Person( age <18 )
>> it gives a warning that you might want to cover Person( age >= 18 ).
>>
>>
>> I'd say that such a warning may not be very useful because
>> - in many cases you may not be interested in the "other" values at
>> all,
>> - in some cases 18, 19,... is handled with Person( age < 50 ) with
low
>> salience (not recommended!),
>> - in many (other) cases you use a (low salience) "catch all" rule
to
>> handle facts not selected by 1st order rules,
>>
>> Moreover, I'm thinking of using additional rules with Verifier, with one
>> of the primary targets being "magic numbers".
>>
>> But Verifier is a fine achievement, and the confiugration is here to get
>> you what you want!
>>
>> -W
>>
>>
>> Toni Rikkola
>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:52 a.m.
Hi Wolfgang,
I was about to report the fact that using drools-verifier 5.2.0 M1 didn't
help, when I saw your comment about checking the error.
Apparently there is something wrong:
### Verifier errors ###
[ERR 101] Line 1:1 no viable alternative at input ':'
Verifier could not form a PackageDescr from the resources that it was trying
to verify.
I do not understand this completely. When I execute the ruleset, it runs as
planned, but this error message seems to imply there is something wrong with
the drl.
Is it a problem that I feed the verifier with
String ruleText =
"C:\\Users\\Frank\\Documents\\DroolsWorkSpaces\\EmpiricalExperiments\\Financial
Rules\\src\\main\\rules\\clearancerules.drl";
verifier.addResourcesToVerify( ResourceFactory.newReaderResource(
new StringReader( ruleText ) ), ResourceType.DRL );
Do the inputs need to be in another format or is there definitely something
wrong in the rules themselves?
Regards,
Frank
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
6:03 a.m.
You are feeding it the pathname, not the text from the file.
-W
On 16 March 2011 11:52, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
Hi Wolfgang,
I was about to report the fact that using drools-verifier 5.2.0 M1 didn't
help, when I saw your comment about checking the error.
Apparently there is something wrong:
### Verifier errors ###
[ERR 101] Line 1:1 no viable alternative at input ':'
Verifier could not form a PackageDescr from the resources that it was
trying
to verify.
I do not understand this completely. When I execute the ruleset, it runs as
planned, but this error message seems to imply there is something wrong
with
the drl.
Is it a problem that I feed the verifier with
String ruleText =
"C:\\Users\\Frank\\Documents\\DroolsWorkSpaces\\EmpiricalExperiments\\Financial
Rules\\src\\main\\rules\\clearancerules.drl";
verifier.addResourcesToVerify(
ResourceFactory.newReaderResource(
new StringReader( ruleText ) ), ResourceType.DRL
);
Do the inputs need to be in another format or is there definitely something
wrong in the rules themselves?
Regards,
Frank
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:06 a.m.
String path = "C:...";
Resource resource = ResourceFactory.newClassPathResource( path, getClass()
);
if( resource != null ){
verifier.addResourcesToVerify( resource, ResourceType.DRL );
} else {
//...
}
On 16 March 2011 12:03, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
You are feeding it the pathname, not the text from the file.
-W
On 16 March 2011 11:52, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
> Hi Wolfgang,
>
> I was about to report the fact that using drools-verifier 5.2.0 M1 didn't
> help, when I saw your comment about checking the error.
>
> Apparently there is something wrong:
> ### Verifier errors ###
> [ERR 101] Line 1:1 no viable alternative at input ':'
> Verifier could not form a PackageDescr from the resources that it was
> trying
> to verify.
>
> I do not understand this completely. When I execute the ruleset, it runs
> as
> planned, but this error message seems to imply there is something wrong
> with
> the drl.
>
> Is it a problem that I feed the verifier with
> String ruleText =
>
> "C:\\Users\\Frank\\Documents\\DroolsWorkSpaces\\EmpiricalExperiments\\Financial
> Rules\\src\\main\\rules\\clearancerules.drl";
> verifier.addResourcesToVerify(
> ResourceFactory.newReaderResource(
>
> new StringReader( ruleText ) ), ResourceType.DRL
> );
>
> Do the inputs need to be in another format or is there definitely
> something
> wrong in the rules themselves?
>
> Regards,
> Frank
>
> --
> View this message in context:
>
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
6:07 a.m.
You may have to use
newFileResource( path )
or change the path.
Sorry
-W
On 16 March 2011 12:06, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
String path = "C:...";
Resource resource = ResourceFactory.newClassPathResource( path, getClass()
);
if( resource != null ){
verifier.addResourcesToVerify( resource, ResourceType.DRL );
} else {
//...
}
On 16 March 2011 12:03, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
> You are feeding it the pathname, not the text from the file.
> -W
>
>
> On 16 March 2011 11:52, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
>
>> Hi Wolfgang,
>>
>> I was about to report the fact that using drools-verifier 5.2.0 M1 didn't
>> help, when I saw your comment about checking the error.
>>
>> Apparently there is something wrong:
>> ### Verifier errors ###
>> [ERR 101] Line 1:1 no viable alternative at input ':'
>> Verifier could not form a PackageDescr from the resources that it was
>> trying
>> to verify.
>>
>> I do not understand this completely. When I execute the ruleset, it runs
>> as
>> planned, but this error message seems to imply there is something wrong
>> with
>> the drl.
>>
>> Is it a problem that I feed the verifier with
>> String ruleText =
>>
>>
"C:\\Users\\Frank\\Documents\\DroolsWorkSpaces\\EmpiricalExperiments\\Financial
>> Rules\\src\\main\\rules\\clearancerules.drl";
>> verifier.addResourcesToVerify(
>> ResourceFactory.newReaderResource(
>>
>> new StringReader( ruleText ) ), ResourceType.DRL
>> );
>>
>> Do the inputs need to be in another format or is there definitely
>> something
>> wrong in the rules themselves?
>>
>> Regards,
>> Frank
>>
>> --
>> View this message in context:
>>
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
>> Sent from the Drools - User mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
6:29 a.m.
Hi Wolfgang,
Yes, you are absolutely right about the path mistake. Can't believe I missed
that. Fixing it removes the errors from the verifier.
However, it still does not return the expected outputs...
System.out.println(result.getVerifierData().getAll().isEmpty()); => returns
false, which is as expected
But the following statement still does not return anything.
for (VerifierMessageBase base : result
.getBySeverity(Severity.WARNING)) {
System.out.println(base);
}
I'm sorry to take so much of your time, I really appreciate your efforts.
Regards,
Frank
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
7:05 a.m.
And no Severity.ERROR or Severity.NOTE either?
What kind of verifier finding(s) do you expect? A rule sample might help.
-W
PS: I'm just investigating this corner of Drools, and you do provide some
inspiration ;-)
On 16 March 2011 12:29, FrankVhh <frank.vanhoenshoven(a)agserv.eu> wrote:
Hi Wolfgang,
Yes, you are absolutely right about the path mistake. Can't believe I
missed
that. Fixing it removes the errors from the verifier.
However, it still does not return the expected outputs...
System.out.println(result.getVerifierData().getAll().isEmpty()); => returns
false, which is as expected
But the following statement still does not return anything.
for (VerifierMessageBase base : result
.getBySeverity(Severity.WARNING)) {
System.out.println(base);
}
I'm sorry to take so much of your time, I really appreciate your efforts.
Regards,
Frank
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:08 a.m.
Can you make few rules for us to test this with.
I have to say that the verifier is not perfect when it searches for redundancy, so your
rules might be too complex for it at the moment.
Toni
On Mar 16, 2011, at 1:29 PM, FrankVhh wrote:
Hi Wolfgang,
Yes, you are absolutely right about the path mistake. Can't believe I missed
that. Fixing it removes the errors from the verifier.
However, it still does not return the expected outputs...
System.out.println(result.getVerifierData().getAll().isEmpty()); => returns
false, which is as expected
But the following statement still does not return anything.
for (VerifierMessageBase base : result
.getBySeverity(Severity.WARNING)) {
System.out.println(base);
}
I'm sorry to take so much of your time, I really appreciate your efforts.
Regards,
Frank
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:30 a.m.
Hi,
Thanks all for your replies.
I forgot I had already uncommented the RHS of a rule, whic onviously did not
return a warning. When I comment it, this warning is displayed.
Sorry to bother you with this trivial problem.
Redundancy, however, isn't detected yet. Neither are the "gaps"
[temperature
= 0] and [precipitation != snow]
I am assuming this has more to do with the rules, than it has to do with
drools verfier.
These are the redundant rules:
=========================================================================
rule "Rule 1"
salience 200 agenda-group "group1"
lock-on-active true
when
$w : Weather( temperature < 0 || precipitation == Weather.SNOW )
$a : Assignment( status == Assignment.INACTIVE)
then
System.out.println("This rule fired");
end
rule "Rule 2"
salience 200 agenda-group "group1"
lock-on-active true
when
$w : Weather( temperature < 0 || precipitation == Weather.SNOW )
$a : Assignment( status == Assignment.INACTIVE)
then
System.out.println("This rule fired");
end
rule "Rule 3"
salience 200 agenda-group "group1"
lock-on-active true
when
$w : Weather( temperature < 0 || precipitation == Weather.SNOW )
$a : Assignment( status == Assignment.INACTIVE)
then
System.out.println("This rule fired");
end
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-verifier-tp268...
Sent from the Drools - User mailing list archive at Nabble.com.
9:23 a.m.
New subject: Detect conflit between rules with Drools Verifier
I want to detect the conflict between the rules with Drools Verifier. For
example the first condition of the second rule is present in the first rule
and the actions to perform are the same in both rules as they demonstrate in
the following case. It works very well when these rules belong to the same
drl file.
--------- fichier a.drl---------------------------
rule "a"
no-loop true
ruleflow-group "group1"
dialect "mvel"
when
A==0
then
Action1
end
rule "b"
no-loop true
ruleflow-group "group1"
dialect "mvel"
when
A==0 && B==1
then
Action1
end
The problem arises when I separated its rules and that I have to put each in
its own file
---------------- a.drl----------------
rule "a"
no-loop true
ruleflow-group "group1"
dialect "mvel"
when
A==0
then
Action1
end
------------------b.drl--------------------
rule "b"
no-loop true
ruleflow-group "group1"
dialect "mvel"
when
A==0 && B==1
then
Action1
end
I can no longer detect this problem with Drools Verifier.
Does anyone ever encountered this problem?
How can I do to write a small program to audit if this case?
--
View this message in context:
http://drools.46999.n3.nabble.com/Drools-verifier-tp2681002p4018170.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
4537
days inactive
5002
days old
16 comments
4 participants
participants (4)
-
FrankVhh -
paco -
Toni Rikkola -
Wolfgang Laun