My point wasn't the technology across bundles -- rather, I'm talking about interop with the DI framework used *within* a bundle.
For example, I may want to use Guice for DI within my bundle, but use Blueprint to expose/consume OSGi services. As it stands, developers have to learn each DI framework's own mechanisms for exposing/consuming services, which means additional complexity, potential compatibility issues (e.g. Spring proxies), and differing maturity of implementation (for example, if my DI framework of choice is Guice, I'm stuck with an immature Peaberry micro-services implementation). -- Raman Gupta VIVO Systems http://vivosys.com On 11/01/2011 09:01 AM, Guillaume Nodet wrote: > You can use OSGi services for that. OSGi services can be exported and > imported irrespective of the underlying technology used. > > On Tue, Nov 1, 2011 at 13:35, Raman Gupta <[email protected] > <mailto:[email protected]>> wrote: > > On 11/01/2011 06:05 AM, Ioannis Canellos wrote: > > Let's not confuse blueprint with spring. Blueprint is > > a declarative way to work with OSGi services and Spring is a > framework > > for creating applications. > > I don't think that Aries has the same focus with Spring but with > SpringDM. > > > > You can always use both, if you have to go with Spring. > > > > If I had to use Spring, I would use it only where its necessary and > > for managing services etc I would use Aries. > > Example: > > In Cellar 90% of the modules use Aries, but there is a single module > > that uses Spring/SpringDM. We don't have any problem with that. > > What would have been nice is if Blueprint provided a way, out of the > box, to expose beans created by Spring or Guice to the Blueprint > context. That way, one could use the DI framework of choice / > annotations inside a bundle, while consistently using Blueprint as a > microservice layer. I'm surprised the Blueprint spec developers didn't > consider interop with existing DI frameworks as a first class spec > item. I suppose such functionality could still be implemented as a > Blueprint extension for each DI framework. > > Regards, > Raman Gupta > VIVO Systems > http://vivosys.com
