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 <fmesc...@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@mail.osgi.org
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> eji...@apache.org
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
