[osgi-dev] Why not just OSGi Declarative Services

Peter Kriens peter.kriens at aqute.biz
Tue Nov 1 09:14:05 EDT 2011


Hmm. There is a VERY big difference imho between DS and Blueprint. DS is focused on handling the dynamics of service dependencies lazily, correctly, and timely ONLY. Blueprint tries to make OSGi easier to use and introduces mechanisms like object assembly in XML, the grace period (and its counterpart dying forever), and damping service dependencies. The trade offs between the two make for quite a big difference. 

Kind regards,

	Peter Kriens





On 1 nov. 2011, at 10:41, Emily Jiang wrote:

> There is not much difference betwen DS and Blueprint. Blueprint offers a good dumping capability to allow bundle in-place update. Personally, I prefer blueprint. Apache aries has the implementation of blueprint spec. 
> Regards
> Emily
> 
> On Fri, Oct 28, 2011 at 7:45 PM, Felix Meschberger <fmeschbe at gmail.com> wrote:
> Hi,
> 
> Am 27.10.2011 um 18:04 schrieb Eugen Reiswich:
> 
> > That's a good question!
> >
> > We are also in a situation where we need to decide whether to use DS or Spring DM. The Spring DM advantages I always hear are:
> > - Spring supports transaction management out of the box. With DS you would need another framework to support TM
> > - Spring has a good Hybernate support
> >
> > Can please someone comment on this?
> 
> I think it is not appropriate to compare DS to Spring DM. This is like comparing a bike to a train system.
> 
> What you might want to do is compare DS to Blueprint.
> 
> I prefer DS, since its more lightweight, easier to use and understand and has great support from the tooling side as well as integration with Configuration Admin.
> 
> Your mileage may vary, though, and you might prefer Blueprint since you are able to write the blueprint XML while sleeping ;-)
> 
> Regards
> Felix
> 
> >
> > Eugen
> >
> > Am 27.10.2011 um 14:04 schrieb Ferry Huberts:
> >
> >> On 10/27/2011 01:09 PM, Mohamed Ragab wrote:
> >>> Hi All,
> >>>
> >>> Just an innocent technical question, please!
> >>>
> >>> Correct me if I am wrong, but to my understanding:
> >>> 1. OSGi has a Service Registry
> >>> 2. OSGi has Declarative Services
> >>> 3. There are multiple options for using Declarative Services without
> >>> writing the XML by hand, like: Bnd annotations, iPojo, Apache Felix SCR
> >>> Annotions, and others. All of which result in the services being
> >>> registered in the OSGi service registry, and lookups for services being
> >>> done from the OSGi Service Registry; Declarative Services as usual
> >>> 4. A standard is in the works for standard OSGi annotations for
> >>> Declarative Services
> >>>
> >>> My question is:
> >>> Are there any technical advantages, for new code written for OSGi, to
> >>> use: Spring DM or Guice+Peaberry
> >>>
> >>
> >>
> >> that basically depends on your personal preference. the end result is
> >> that your services are registered in the OSGi service registry. how it
> >> got there isn't really very relevant.
> >>
> >> every framework has its own advantages and disadvantages.
> >>
> >> I'd say that when going from lightweight to heavyweight you'd have the
> >> following list:
> >>
> >> DS
> >> DS + Guice
> >> DS + Spring
> >>
> >>
> >> I think (last I heard from Peter) that the annotations are close to final.
> >>
> >>
> >> --
> >> Ferry Huberts
> >> _______________________________________________
> >> OSGi Developer Mail List
> >> osgi-dev at mail.osgi.org
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev at mail.osgi.org
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> 
> 
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev at mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> 
> 
> 
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
> 
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev at mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.osgi.org/pipermail/osgi-dev/attachments/20111101/7be28493/attachment.html


More information about the osgi-dev mailing list