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

[Cristiano Gavião]

On 19-08-2014 22:05, Mark Proctor wrote:
> One point to remember is that OSGI Activators did not work out of the 
> box for optional runtime plugins. Which is why we had to use custom 
> trackers, look at how the decision tables stuff is done. We’d need to 
> see if the blueprints approach can solve this problem.
certainly it will not be a problem, once we eliminate the import/use of 
not api packages from/to modules, the tight coupling of modules through 
the static factories and find a smart solution to synchronize the 
"internal service registry" with the osgi one...
>
> We should also move this chat over to the new google groups :)

Ok, to me but there we can have shared discussion between groups ? or 
should we have same kind of discussion in both jbpm and drools groups ?
>
> Mark
> On 18 Aug 2014, at 17:44, Cristiano Gavião <cvgaviao at gmail.com 
> <mailto:cvgaviao at gmail.com>> wrote:
>
>> 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
>>
>> <KieDroolsJbpmActivators.ods>_______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20140820/59d5a536/attachment.html