[rules-dev] [osgi-dev] Provide both blueprint and DS ?

Cristiano Gavião cvgaviao at gmail.com
Sat Mar 30 10:22:22 EDT 2013


Mark,

I had a detailed look into all the interfaces at kie-api. In general I 
liked what I saw, mainly the service oriented approach.

 From an OSGi point of view, some of those interfaces will need to be 
implemented by osgi specific classes due to classloading and IO issues, 
besides the fact that OSGi already has some strengths that must be used, 
aka: modularity, events, service registration, services factories, 
dynamic configuration service, remote service calling and so on.

So probably we will end with some like kie-osgi-services that will wrap 
kie-impl.

What I didn't like was the intense use of the Static Factory pattern, as 
the one that I found into org.kie.api.KieServices.Factory. That pattern 
is really evil in both DI and OSGi world.
To make that work in OSGi I would need to have a dependency from API to 
the IMPL that brokes the benefits of modularity:

> INSTANCE = ( KieServices ) Class.forName( 
> "org.drools.compiler.kie.builder.impl.KieServicesImpl" ).newInstance();

@Charles, my idea is to remove the activators from each kie and drools 
bundles and do the services exposition at some osgi specific projects: 
one for kie, one for drools.

Let me know your thoughts.

regards,

Cristiano

On 29/03/13 14:56, Mark Proctor wrote:
> Only things in -api are considered stable and should be used by users and external services.
>
> Mark
> On 29 Mar 2013, at 13:04, Cristiano Gavião <cvgaviao at gmail.com> wrote:
>
>> Hi Charles,
>> I opened a discussion in OSGi dev list to get some feedbacks about the use of DI (Blueprint, CDI, Google) and DS. I got some interested notes there. (http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg02684.html)
>>
>> I'm in favor of having Drools and DS + Services, too...
>>
>> Btw, have you investigated about the services to be exposed bye KIE and Drools?
>>
>> @Mark,
>> I saw a lot of "*service" interfaces in new code. But I guess only a few of them are for external uses. Could you point us which interfaces are intent to be used by an external api? thanks.
>>
>> regards,
>>
>> Cristiano
>>



More information about the rules-dev mailing list