services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?

Cristiano Gavião
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 ?

many thanks,

Cristiano
_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|

Re: services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?

Mark Proctor
I think things have evolved organically here. We probably need to do a full review, to ensure consistency.

I suspect know one would know the answers, without having to dig in the code first.

Mark

On 15 Aug 2014, at 16:02, Cristiano Gavião <[hidden email]> wrote:

> 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 ?
>
> many thanks,
>
> Cristiano
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|

Re: services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?

Cristiano Gavião
I agree that should have a consistency.

but where should we start from ?

are you able to point me to any resource describing a good setup
workflow using that new stuffs that I can use as base for my own
investigation?

The examples that I saw until now are using factories. what I can
remember last time I tried 6.x, that factories won't work in osgi, so
they are good candidates to be registered by those activators.

Cristiano

On 15-08-2014 13:22, Mark Proctor wrote:

> I think things have evolved organically here. We probably need to do a full review, to ensure consistency.
>
> I suspect know one would know the answers, without having to dig in the code first.
>
> Mark
>
> On 15 Aug 2014, at 16:02, Cristiano Gavião <[hidden email]> wrote:
>
>> 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 ?
>>
>> many thanks,
>>
>> Cristiano
>> _______________________________________________
>> rules-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|

Re: services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?

Mark Proctor
best thing to do is come onto irc, and we can start browsing classes together.

Mark
On 16 Aug 2014, at 15:18, Cristiano Gavião <[hidden email]> wrote:

> I agree that should have a consistency.
>
> but where should we start from ?
>
> are you able to point me to any resource describing a good setup
> workflow using that new stuffs that I can use as base for my own
> investigation?
>
> The examples that I saw until now are using factories. what I can
> remember last time I tried 6.x, that factories won't work in osgi, so
> they are good candidates to be registered by those activators.
>
> Cristiano
>
> On 15-08-2014 13:22, Mark Proctor wrote:
>> I think things have evolved organically here. We probably need to do a full review, to ensure consistency.
>>
>> I suspect know one would know the answers, without having to dig in the code first.
>>
>> Mark
>>
>> On 15 Aug 2014, at 16:02, Cristiano Gavião <[hidden email]> wrote:
>>
>>> 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 ?
>>>
>>> many thanks,
>>>
>>> Cristiano
>>> _______________________________________________
>>> rules-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>> _______________________________________________
>> rules-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|

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

Cristiano Gavião
In reply to this post by 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

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev

KieDroolsJbpmActivators.ods (51K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mark Proctor
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.

We should also move this chat over to the new google groups :)

Mark
On 18 Aug 2014, at 17:44, Cristiano Gavião <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|

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

Charles Moulliard
Hi,

Before to review the code, it could be interesting to define/describe in a document the services/factories that we need to work with Drools/BPMN, dependencies between the modules/jar (= Packages to be exported/imported) and next we could see how we could improve the design of what has been done for OSGI. Aries Blueprint could be used or Apache DS to inject dependency (less code and dependencies are needed vs Blueprint) but Weld/CDI is also another option since that pax-cdi has been released but I should have a look to verify stability, ...

Regards,

Charles

On Wed, Aug 20, 2014 at 3:05 AM, Mark Proctor <[hidden email]> 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.

We should also move this chat over to the new google groups :)

Mark
On 18 Aug 2014, at 17:44, Cristiano Gavião <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|

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

Cristiano Gavião
In reply to this post by Mark Proctor




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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev



_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|

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

Mark Proctor
the core jBPM devs involved in this work are on the drools dev list anyway, so should be fine to have it all done in one place. If there are later jbPM specific bits still ongoing, it can move to that list. You can also send summary updates, if you wish to the other list, to keep people in in sync.

Mark
On 20 Aug 2014, at 15:01, Cristiano Gavião <[hidden email]> wrote:





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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev



_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev