[jbpm-dev] services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?

[Cristiano Gavião]

Kris and Mark,

I passed this morning analyzing the activators... I'm attaching a sheet 
where I added all Activators being used by Kie, JBPM and Drools. Note 
that where I marked with red I saw "signs of smell things" and added a 
comment...

below I write the reasons I think that we should to remove completely 
those activators...

On 18-08-2014 07:28, Kris Verlaenen wrote:
> Cristiano,
>
> Cristiano Gavião schreef op 15/08/2014 17:02:
>> Hi,
>>
>> has a long time that I don't play with Drools and JBPM source code. This
>> week I was walking through them again and saw a lot of new elements,
>> interfaces and new ways to setup things.
>>
>> I saw that some Blueprint specific annotations and classes were created
>> (kie-aries-blueprint).
>> But the existent osgi activators are still registering some services
>> that seems not be appropriated anymore. at least they are different from
>> the set of elements in blueprint namespace (environment, kmodule, kbase
>> and others ) that I saw.
>>
>> For example, in activator of drools-core we have a
>> KnowledgeBaseFactoryServiceImpl being registered. in drools-compiler we
>> have KnowledgeBuilderFactoryServiceImpl being registered.
>>
>> I can't use blueprint, so I need to figure out what is the best setup
>> workflow for OSGi and get the proper services registered.
>>
>> Question, is the kie-aries-blueprint.xsd reflecting the actual state of
>> kie, drools and jbpm core setup workflow, so I can use it as start 
>> point?
>>
>> could someone check that and give me a feedback ?
> It is true that using factories isn't always trivial in OSGi,
well, in reality static factory is not recommended at all in osgi. just 
because normally it is implemented adding a strong "dependency" between 
API and one Implementation. and that is against modularity that OSGi 
preaches. In those scenarios in order to change an implementation almost 
all the times you will need to change the api also.

I saw the addition of ServiceRegistryImpl to concentrate the services 
without a DI. that  would reduced a bit this problem (btw, I saw some 
factories where it isn't being used yet: org.kie.api.KieServices) but 
not all... to me the best solution for non-osgi to separate API from 
Implementor still is JavaSE Service Locator.

> so the activators you are referring to are used (internally) to do 
> additional registration for OSGi.  They should be working and are 
> required when using OSGi.
Maybe those activators used to be required and useful (internally) some 
day. But currently, I don't think they are needed anymore.

The reasons I think they should be removed:

First, there many services being registered using interfaces from 
non-API packages;

Second, the focus of RedHat seems to be Fusion/ Karaf and they already 
use blueprint natively.

Third, there are a project exclusive for blueprint based setup, so 
doesn't make any sense to me to use ServiceTracker and register things 
"by hand in activator" and then complement that using blueprint. Why not 
just use blueprint  ??

Fourth, we can't use one of the most useful features of OSGi, the 
Configuration Admin service. So, we can't (re)configure the registered 
services at runtime using simple service properties...

Fifth, those activators don't scale ! if I have an environment 
(multi-tenant) where I need to have more than one version running same 
time.

So, would help much more if those activators were removed, and improve 
the blueprint project to register all that is needed for it. after that 
we could create other projects for people wanting to use OSGi 
Declarative Services and maybe a OSGi CDI just like the Blueprint one....

And I bet we could figure out a much more clever way to synchronize the 
"internal registry" with the OSGi service registry instead have to call 
ServiceRegistryImpl.getInstance().registerLocator inside the activator 
(Drools-Compiler). One possibility is to create an OSGi implementation 
for ServiceRegistry interface instead use ServiceRegistryImpl in all places.



>
> On top of this, some additional "sugar" was created that allows you to 
> more easily define various elements (kbase, env, etc.) so they can be 
> injected more easily.  You are free to use these, but this is not 
> required, you could initialize these elements yourself using pure Java 
> as well for example.  Afaik, kie-aries-blueprint.xsd should be 
> up-to-date.
>
> There are some osgi examples available here:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-itest/src/test/java/org/drools/karaf/itest/KieSpringOnKarafTest.java 
>
>
> Kris

On 18-08-2014 07:28, Kris Verlaenen wrote:
> Cristiano,
>
> Cristiano Gavião schreef op 15/08/2014 17:02:
>> Hi,
>>
>> has a long time that I don't play with Drools and JBPM source code. This
>> week I was walking through them again and saw a lot of new elements,
>> interfaces and new ways to setup things.
>>
>> I saw that some Blueprint specific annotations and classes were created
>> (kie-aries-blueprint).
>> But the existent osgi activators are still registering some services
>> that seems not be appropriated anymore. at least they are different from
>> the set of elements in blueprint namespace (environment, kmodule, kbase
>> and others ) that I saw.
>>
>> For example, in activator of drools-core we have a
>> KnowledgeBaseFactoryServiceImpl being registered. in drools-compiler we
>> have KnowledgeBuilderFactoryServiceImpl being registered.
>>
>> I can't use blueprint, so I need to figure out what is the best setup
>> workflow for OSGi and get the proper services registered.
>>
>> Question, is the kie-aries-blueprint.xsd reflecting the actual state of
>> kie, drools and jbpm core setup workflow, so I can use it as start 
>> point?
>>
>> could someone check that and give me a feedback ?
> It is true that using factories isn't always trivial in OSGi, so the 
> activators you are referring to are used (internally) to do additional 
> registration for OSGi.  They should be working and are required when 
> using OSGi.
>
> On top of this, some additional "sugar" was created that allows you to 
> more easily define various elements (kbase, env, etc.) so they can be 
> injected more easily.  You are free to use these, but this is not 
> required, you could initialize these elements yourself using pure Java 
> as well for example.  Afaik, kie-aries-blueprint.xsd should be 
> up-to-date.
>
> There are some osgi examples available here:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-itest/src/test/java/org/drools/karaf/itest/KieSpringOnKarafTest.java 
>
>
> Kris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: KieDroolsJbpmActivators.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 38395 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbpm-dev/attachments/20140818/6fb3f7da/attachment-0001.ods