On 30/03/13 13:48, Mark Proctor wrote:
When in non osgi code you need a static method to retrieve the root
service, otherwise you have to use "new". No way around that without something
like CDI or OSGi.
In my opinion, the static factory is a programming facility that costs
too much... it prevents the extendability.
Well, I don't see problems in using "new" or getting instances from an
Abstract Factory, even in JavaSE.
Something else to be aware of:
ServiceRegistryImpl and ServiceRegistry
The ServiceRegistry uses a service locator pattern, that is designed to abstract
containers. The default implementation is reflection based, but it has OSGi wrappers too.
This way we can build services, and they can work standalone or with OSGi or Spring or
what ever, without tieing our core implementations to one specific service implementation.
that sounds good, but wouldn't ServiceRegistry interface be at kie-api
instead of kie-internal ?
On 30 Mar 2013, at 14:22, Cristiano Gavião <cvgaviao(a)gmail.com> wrote:
> I had a detailed look into all the interfaces at kie-api. In general I liked what I
saw, mainly the service oriented approach.
> From an OSGi point of view, some of those interfaces will need to be implemented by
osgi specific classes due to classloading and IO issues, besides the fact that OSGi
already has some strengths that must be used, aka: modularity, events, service
registration, services factories, dynamic configuration service, remote service calling
and so on.
> So probably we will end with some like kie-osgi-services that will wrap kie-impl.
> What I didn't like was the intense use of the Static Factory pattern, as the one
that I found into org.kie.api.KieServices.Factory. That pattern is really evil in both DI
and OSGi world.
> To make that work in OSGi I would need to have a dependency from API to the IMPL that
brokes the benefits of modularity:
>> INSTANCE = ( KieServices ) Class.forName(
> @Charles, my idea is to remove the activators from each kie and drools bundles and do
the services exposition at some osgi specific projects: one for kie, one for drools.
> Let me know your thoughts.
> On 29/03/13 14:56, Mark Proctor wrote:
>> Only things in -api are considered stable and should be used by users and
>> On 29 Mar 2013, at 13:04, Cristiano Gavião <cvgaviao(a)gmail.com> wrote:
>>> Hi Charles,
>>> I opened a discussion in OSGi dev list to get some feedbacks about the use of
DI (Blueprint, CDI, Google) and DS. I got some interested notes there.
>>> I'm in favor of having Drools and DS + Services, too...
>>> Btw, have you investigated about the services to be exposed bye KIE and
>>> I saw a lot of "*service" interfaces in new code. But I guess only
a few of them are for external uses. Could you point us which interfaces are intent to be
used by an external api? thanks.