[rules-dev] PackageBuilder Warnings question

[Edson Tirelli]

   Mikael,

   The existing configuration framework for drools is pretty flexible and
should give you all you need in terms of configuration support. Basically,
chose a prefix, like:

drools.messages.

    And then for each error, choose an ID. For instance, rule update error
could be ruleUpdate. Then the user can do:

drools.messages.ruleUpdate = error

    Or

drools.messages.ruleUpdate = info

    You have access to such properties in the KnowledgeBuilderConfiguration
class automatically, but to keep consistency, just create a
MessageSeverityOption class to use in the API.

kbuilderConf.setOption( MessageSeverityOption.get( "ruleUpdate", ERROR ) );

    There are many examples with all configurations in Drools.

    Only thing is I don't like the term Message I used in the examples above
and Error is too generic... need to think about the proper term.

    Edson

2011/8/25 Mikael Lönneberg <emil at snickeboa.com>

> Hi Edson,
>
> I think we are actually in agreement here as the ProblemTypes could easily
> be renamed to Severity instead..
>
> I will have to think through how to expose the different message types that
> should be possible to override.
>
> Kind Regards
>
> Mikael
>
>
> On Thu, Aug 25, 2011 at 2:02 AM, Edson Tirelli <ed.tirelli at gmail.com>wrote:
>
>>
>>    Hi Mikael,
>>
>>    One idea would be to define severities for compilation messages...
>> could be 1..3, could be INFO, WARN, ERROR, etc. Each problem would have a
>> default priority and in an ideal world, the user could override this
>> priority (like you can do it in eclipse). So, for instance, a rule update
>> could have a default severity of INFO, but if the user does not use dynamic
>> rule updates, he would be able to define it as severity ERROR.
>>
>>    ERRORS would always prevent execution, while warnings and infos would
>> be reported, but not prevent usage.
>>
>>    This is my opinion would be a great step forward compared to what we
>> have today.
>>
>>    What do you think?
>>
>>    Thanks,
>>       Edson
>>
>> 2011/8/24 Mikael Lönneberg <emil at snickeboa.com>
>>
>>> Hi I'm currently working on an implementation of a new type of problem
>>> type namely Warnings, to solve the following JIRA's:
>>> JBRULES-3124, JBRULES-3063, JBRULES-2730
>>>
>>> One of the JIRA's deal with the detection of duplicate rules and another
>>> with detection of duplicate functions.
>>> The question I have is in regards to this is, the current implementation
>>> allows for rules and functions to be overridden by functions and rules
>>> defined in different .drl files.
>>> In order to not break backwards compatibility and allow people to
>>> continue with this behavior we could just create a warning for these types
>>> of issues which is reported through a new getProblems(ProblemType...
>>> problemTypes) to get the problem types you are interested in, we will leave
>>> the legacy method getErrors() for backward compatibility. Another approach
>>> or complementary approach is to for certain types of these Warnings
>>> configure the compiler to be more or less strict, which in turn would switch
>>> the Type of these issues from Warning to Error. Is this something that's
>>> desirable or would it be sufficient to just report these issues as warnings
>>> and leave the responsibility to the user to halt execution if certain
>>> Warnings exists?
>>>
>>> Kind Regards
>>>
>>> Mikael (gwendo)
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>>
>> --
>>   Edson Tirelli
>>   JBoss Drools Core Development
>>   JBoss by Red Hat @ www.jboss.com
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>


-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110825/a7070795/attachment-0001.html