[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] Declarative Services vs Spring

How embarrassing - I meant 291! From my reading of it, the intent was to
institute the OSGi-R4 base. Is that the case, or will it attempt to extend
the standard. Perhaps standardizing OSGi in the JCP and unifying the OSGi
and Spring visions is a bit ambitious for a single JSR. And of course it
would break the symmetry between 291 and 232...

Ah well, plenty of fertile ground for the future.

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 10:02 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Declarative Services vs Spring


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
>
>
>



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.