<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 19-08-2014 22:05, Mark Proctor
wrote:<br>
</div>
<blockquote
cite="mid:FD746FDA-CF56-4A81-B555-D8E7F4FAEBA2@codehaus.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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.</blockquote>
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...<br>
<blockquote
cite="mid:FD746FDA-CF56-4A81-B555-D8E7F4FAEBA2@codehaus.org"
type="cite">
<div><br>
</div>
<div>We should also move this chat over to the new google groups
:)</div>
</blockquote>
<br>
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 ?<br>
<blockquote
cite="mid:FD746FDA-CF56-4A81-B555-D8E7F4FAEBA2@codehaus.org"
type="cite">
<div><br>
</div>
<div>Mark<br>
<div>
<div>On 18 Aug 2014, at 17:44, Cristiano Gavião <<a
moz-do-not-send="true" href="mailto:cvgaviao@gmail.com">cvgaviao@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">Kris and Mark,<br>
<br>
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...<br>
<br>
below I write the reasons I think that we should to remove
completely those activators...<br>
<br>
On 18-08-2014 07:28, Kris Verlaenen wrote:<br>
<blockquote type="cite">Cristiano,<br>
<br>
Cristiano Gavião schreef op 15/08/2014 17:02:<br>
<blockquote type="cite">Hi,<br>
<br>
has a long time that I don't play with Drools and JBPM
source code. This<br>
week I was walking through them again and saw a lot of
new elements,<br>
interfaces and new ways to setup things.<br>
<br>
I saw that some Blueprint specific annotations and
classes were created<br>
(kie-aries-blueprint).<br>
But the existent osgi activators are still registering
some services<br>
that seems not be appropriated anymore. at least they
are different from<br>
the set of elements in blueprint namespace
(environment, kmodule, kbase<br>
and others ) that I saw.<br>
<br>
For example, in activator of drools-core we have a<br>
KnowledgeBaseFactoryServiceImpl being registered. in
drools-compiler we<br>
have KnowledgeBuilderFactoryServiceImpl being
registered.<br>
<br>
I can't use blueprint, so I need to figure out what is
the best setup<br>
workflow for OSGi and get the proper services
registered.<br>
<br>
Question, is the kie-aries-blueprint.xsd reflecting
the actual state of<br>
kie, drools and jbpm core setup workflow, so I can use
it as start point?<br>
<br>
could someone check that and give me a feedback ?<br>
</blockquote>
It is true that using factories isn't always trivial in
OSGi,<br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite">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.<br>
</blockquote>
Maybe those activators used to be required and useful
(internally) some day. But currently, I don't think they
are needed anymore.<br>
<br>
The reasons I think they should be removed:<br>
<br>
First, there many services being registered using
interfaces from non-API packages;<br>
<br>
Second, the focus of RedHat seems to be Fusion/ Karaf and
they already use blueprint natively.<br>
<br>
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 ??<br>
<br>
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...<br>
<br>
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.<br>
<br>
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....<br>
<br>
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.<br>
<br>
<br>
<br>
<blockquote type="cite"><br>
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.<br>
<br>
There are some osgi examples available here:<br>
<a moz-do-not-send="true"
href="https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-itest/src/test/java/org/drools/karaf/itest/KieSpringOnKarafTest.java">https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-itest/src/test/java/org/drools/karaf/itest/KieSpringOnKarafTest.java</a><span
class="Apple-converted-space"> </span><br>
<br>
Kris<br>
</blockquote>
<br>
On 18-08-2014 07:28, Kris Verlaenen wrote:<br>
<blockquote type="cite">Cristiano,<br>
<br>
Cristiano Gavião schreef op 15/08/2014 17:02:<br>
<blockquote type="cite">Hi,<br>
<br>
has a long time that I don't play with Drools and JBPM
source code. This<br>
week I was walking through them again and saw a lot of
new elements,<br>
interfaces and new ways to setup things.<br>
<br>
I saw that some Blueprint specific annotations and
classes were created<br>
(kie-aries-blueprint).<br>
But the existent osgi activators are still registering
some services<br>
that seems not be appropriated anymore. at least they
are different from<br>
the set of elements in blueprint namespace
(environment, kmodule, kbase<br>
and others ) that I saw.<br>
<br>
For example, in activator of drools-core we have a<br>
KnowledgeBaseFactoryServiceImpl being registered. in
drools-compiler we<br>
have KnowledgeBuilderFactoryServiceImpl being
registered.<br>
<br>
I can't use blueprint, so I need to figure out what is
the best setup<br>
workflow for OSGi and get the proper services
registered.<br>
<br>
Question, is the kie-aries-blueprint.xsd reflecting
the actual state of<br>
kie, drools and jbpm core setup workflow, so I can use
it as start point?<br>
<br>
could someone check that and give me a feedback ?<br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
There are some osgi examples available here:<br>
<a moz-do-not-send="true"
href="https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-itest/src/test/java/org/drools/karaf/itest/KieSpringOnKarafTest.java">https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-itest/src/test/java/org/drools/karaf/itest/KieSpringOnKarafTest.java</a><span
class="Apple-converted-space"> </span><br>
<br>
Kris<br>
</blockquote>
<br>
<span><KieDroolsJbpmActivators.ods></span>_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a></pre>
</blockquote>
<br>
</body>
</html>