[rules-users] kie-sprind xsd for spring 4
Mark Proctor
mproctor at codehaus.org
Mon Mar 3 20:26:35 EST 2014
We do need to make it easier to unit test things. One idea is to allow annotations in a unit test to declare the subset of rules in scope for testing. The annotation could specify a package, a rule or even 1..n qualifiers. If rules have qualifier annotations on them, they would be sucked in.
I think the next thing would then be to give manual control of the agenda cycle. So instead of calling fireAllRules() and then all rules firing, and checking the results. The code would allow the unit test to “step” through the rule firings in turn, asserting the results as it did so.
Another idea to unit test would be to disconnect a rule from the working memory and simply test it as a data flow. Given X as a data source, what are the resulting rows of data. This would allow to check the logic of the pattern matching.
Look forward to seeing your progress with the spring annotation idea, these things can often take many revision to get right. The only other thing to remember is that classes are static, not much we can do about that. So it would be harder to have incremental changes, compared to updating a kmodule.xml. But that may be a limitation people are happy to live with.
Mark
On 3 Mar 2014, at 09:49, Stephen Masters <stephen.masters at me.com> wrote:
> Hi Mark,
>
> Thanks for getting back to me about this.
>
> Actually, when I mentioned that I was making the project public a bit prematurely, the source of the knowledge base was one of the main reasons. At the moment the rules are hard-coded in that class path location for a couple of reasons. Firstly, I find them easier to ‘unit’ test that way. I like to create a knowledge base containing only the rules under test. However the main reason is that at the moment I’m just exploring what a ‘question’ could look like. The intention is to switch to a mechanism whereby users are able to add questions to the system at runtime. When I switch over to that, I’ll be taking another look at the best ways to do it in 6.x.x.
>
> When it comes to annotations, it’s relatively straightforward to do what you mention in Spring. I keep thinking about knocking it up myself, although at the moment I’m finding that writing the @Bean methods in a @Configuration class gives me the flexibility I need while I’m exploring options.
>
> I’m going to keep working on improving this little demo app, and I’ll let you know when any significant new functionality (such as the above) is added. Hopefully a few folks will find it useful. If nothing else, it can be a discussion point for good/bad ways of doing things. The shortage of example projects out there is a real barrier to getting started with Drools.
>
> Steve
>
>
>> On 2 Mar 2014, at 20:28, Mark Proctor <mproctor at codehaus.org> wrote:
>>
>>> i’m open to allowing mixing and matching of annotations and xml configuration. Although what’s published on the qzr sort of goes against the grain of what we are trying to achieve - such as not specifying individual asset files.
>>> public KieServicesBean kieServices() throws KieBuildException {
>>> DroolsResource[] resources = new DroolsResource[]{
>>> new DroolsResource("rules/health-quiz.drl",
>>> ResourcePathType.CLASSPATH,
>>> ResourceType.DRL)};
>>>
>>> KieServicesBean bean = new DefaultKieServicesBean(resources);
>>> return bean;
>>> }
>>>
>>> While you can do anything from programmatic factories, and you don’t “lose” any functionality, in it’s current form it doesn’t promote convention and configuration approach. I really want to avoid any method code, other than configuring say listeners. Ideally we’d be looking for something like below, that mirrors what we have in the xml already, and avoids authoring any methods at all. I know I could do this in CDI, but I don’t know about Spring. In CDI I can scan for usages of @KBaseConfig. Where I find a @KBaseConfig I can populate the main CDI beans infrastructure, so it treats xml configuration and annotation configuration the same.
>>>
>>>
>>> @KBaseConfig(name=“kbase1”, packages=“my.domain.fld, my.domain.fld2" )
>>> public static class kbase1Config {
>>>
>>> @KSessionConfig(name=“ksession1”, clockType=“pseudo”)
>>> private KieSession kieSession1;
>>>
>>> @KSessionConfig(name=“ksession2”, clockType=“realtime”)
>>> private KieSession kieSession2;
>>> }
>>>
>>> The above is the same as:
>>> <kbase name==“kbase1”, packages=“my.domain.fld, my.domain.fld2”>
>>> <ksession name=“ksession1” clockType=“pseudo” />
>>> <ksession name=“ksession1” clockType=“realtime” />
>>> </kbase>
>>>
>>> Mark
>>>
>>> On 1 Mar 2014, at 23:29, Stephen Masters <stephen.masters at me.com> wrote:
>>>
>>>> It definitely wouldn’t miss out on any Drools 6 functionality. It enables you to use everything that is available in 6.x because it give you direct access to the API.
>>>>
>>>> Steve
>>>>
>>>>
>>>> On 28 Feb 2014, at 19:41, vinodkiran <vinodkiran at usa.net> wrote:
>>>>
>>>>> Steve,
>>>>>
>>>>> Interesting approach. I am looking through your code.
>>>>>
>>>>> It seems to me that using the JavaConfig approach would miss some of the
>>>>> changes introduced in Drools 6.0.
>>>>>
>>>>> Look at this article by Mark,
>>>>>
>>>>> http://blog.athico.com/2013/10/configuration-and-convention-based.html
>>>>>
>>>>>
>>>>>
>>>>> -- Vinod
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://drools.46999.n3.nabble.com/Kie-sprind-xsd-Are-the-configuration-options-limited-compare-to-drools-spring-xsd-tp4028383p4028431.html
>>>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> rules-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140304/1b7315f4/attachment-0001.html
More information about the rules-users
mailing list