Re: [equinox-dev] Declarative Services vs Spring

["Neil Bartlett" <neil@xxxxxxxxxxxxxx>]

Joel,

The puzzling thing about JSR 277 is that it fails to answer the
standard question "Why isn't this need met by existing
specifications?". No JSR should exist if it can't give a satisfactory
answer to that question.

It goes on to reject OSGi R3 but is silent on OSGi R4. In fact all of
the reasons given for rejecting R3 are not applicable to R4. So what
is the need for JSR 277? It appears to be a case of "Not Invented
Here" syndrome.

We now have JSR 291 which aims to turn OSGi itself into a
JCP-supported Java standard. I think this the one that will gather a
community around it and deliver something really useful, whereas 277
has conspicuously failed to do anything at all yet.

- Neil



On 3/2/06, Hawkins, Joel <Joel.Hawkins@xxxxxxxxxxxxx> wrote:
>
>
> Are  any Spring representitives involved in this JSR? It seems like a promising  vehicle for convergence.
>
>
> http://www.jcp.org/en/jsr/detail?id=277
>
> Cheers,
>
> Joel  Hawkins
>
>
> -----Original Message-----
> From:    equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx]On    Behalf Of Neil Bartlett
> Sent: Thursday, March 02, 2006 8:53    AM
> To: Equinox development mailing list
>
> Subject: Re:    [equinox-dev] Declarative Services vs    Spring
>
>
>
> Subbarao,
>
> I think you're probably right.    Having played with Declarative Services in the last few days, I really miss    the flexibility and expressiveness of Spring's DI capabilities.
>
> I've    just been to a seminar given by Rod Johnson where he mentioned that they are    working on OSGi integration with Spring, ie making Spring more dynamic so that    it will work properly within an OSGi runtime. That's very exciting for me    because I think that OSGi combined with Spring's rich framework and AOP    features would be an incredible platform for enterprise services. It would    blow away anything previously possible with J2EE and EJB.
>
> Unfortunately Rod said that this functionality is probably something    that will be in Spring 3.0, where Spring is currently in 2.0 M1. As an    alternative from the OSGi side, DS could be made more powerful so it could    replace Spring's DI capabilities, while still making use of the other two    sides of the "Spring triangle".
>
> Neil
>
>
>
> On 3/1/06, Subbarao    Meduri <mkv@xxxxxxxxxx>    wrote:
> >
> >
> >
> > Agreed that OSGi is a more dynamic platform, and thus could say      constructor injection is not the best thing that components should      implement. However, if you take the view that OSGi is also a integration      platform for components (where you don't necessarily have control over how a      component is designed), it would make sense to me that declarative services      support constructor injection. Obviously, it would not be a best practice,      but it at least it will not inhibit a component that is not designed to      leverage OSGi dynamic features from being integrated into the framework.
> >
> > Thoughts ?
> > Subbarao
> >
> > "Neil Bartlett" <      neil@xxxxxxxxxxxxxx>
> >
> >
> >
> >
> >
> >
> >
> > "Neil Bartlett" <neil@xxxxxxxxxxxxxx>
> > Sent by: equinox-dev-bounces@xxxxxxxxxxx
> >
> > 03/01/2006 10:21 AM
> >
> > Please respond                          to
> > Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> >
> >
> > To
> > "Equinox development mailing                  list" <equinox-dev@xxxxxxxxxxx>
> >
> >
> > cc
> >
> >
> >
> > Subject
> > Re: [equinox-dev] Declarative                  Services vs Spring
> >
> >
> > I      think that's intentional. With OSGi you always have to be aware that
> > the      services you depend on might go away, and possibly come back again
> > later.      That's the essence of OSGi - it's dynamic. In this context an
> > "immutable      final service reference" is an oxymoron.
> >
> > Spring lives in a      comfortable static world where dependencies, once
> > supplied, will live for      at least as long as the things that depend on
> > them. In OSGi, that kind of      assumption is only really valid for
> > intra-bundle dependencies. DS on the      other can handle dynamic
> > inter-bundle dependencies, which IMHO makes it      much more powerful.
> >
> > On the other hand Spring has much more to it than      dependency
> > injection. It also has a number of very powerful libraries, eg      for
> > developing DAOs using JDBC or O/R mappers, an AOP library,      remoting
> > libraries, etc. Because Spring is wonderfully modular, you can      use as
> > much or as little of it as you like (just like Eclipse!).
> >
> > -      Neil
> >
> >
> > On 3/1/06, Subbarao Meduri <mkv@xxxxxxxxxx>      wrote:
> > >
> > >
> > > How does declarative services fare when      compared with Spring framework in
> > > terms of its injection      capabilities ? My apologies if this is already
> > > discussed on this      forum.
> > >
> > >  Is there a reason why declarative services does      not support constructor
> > > injection, for example ? It seems      constructor injection is the only way to
> > > initialize a component that      holds a immutable (final) service reference
> > > injected via its      constructor.
> > >
> > >  Appreciate your thoughts.
> > >
> > >       Regards,
> > >  Subbarao
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > equinox-dev      mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> >
> >
> >
>
>
>
>
>
>
>
> The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>