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 ? > > Mark > > On 30 Mar 2013, at 14:22, Cristiano Gavião <cvgav...@gmail.com> wrote: > >> Mark, >> >> 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( >>> "org.drools.compiler.kie.builder.impl.KieServicesImpl" ).newInstance(); >> @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. >> >> regards, >> >> Cristiano >> >> On 29/03/13 14:56, Mark Proctor wrote: >>> Only things in -api are considered stable and should be used by users and >>> external services. >>> >>> Mark >>> On 29 Mar 2013, at 13:04, Cristiano Gavião <cvgav...@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. >>>> (http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg02684.html) >>>> >>>> I'm in favor of having Drools and DS + Services, too... >>>> >>>> Btw, have you investigated about the services to be exposed bye KIE and >>>> Drools? >>>> >>>> @Mark, >>>> 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. >>>> >>>> regards, >>>> >>>> Cristiano >>>> _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
