I should add the private fields don’t really do anything in this example, they are just
placeholders for the annotations, and it’s the annotations that are used to build the CDI
Beans. Potentially you could make the “name” attribute optional, and if it doesn’t exist
it would use the method or class name.
We could probably allow Qualifiers to be used, so that we get type safe injection, instead
of using String names. The qualifier can only be used on one “producer” point, i.e. a
single place in any Config file.
@KBaseConfig(name=“kbase1”, packages=“my.domain.fld, my.domain.fld2" )
public class kbase1Config {
@KSessionConfig(name=“ksession1”, clockType=“pseudo”)
@QualifiedBinding( MyKSession.class )
private KieSession kieSession1;
@KSessionConfig(name=“ksession2”, clockType=“realtime”)
private KieSession kieSession2;
}
public class MyApp {
@Inject @MyKSession;
private KieSession ksession1;
}
On 2 Mar 2014, at 20:28, Mark Proctor <mproctor(a)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(a)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(a)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-op...
>> Sent from the Drools: User forum 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