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 <cvgav...@gmail.com
<mailto:cvgav...@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@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
