[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Declarative Services vs Spring
- From: "Neil Bartlett" <neil@xxxxxxxxxxxxxx>
- Date: Wed, 1 Mar 2006 15:21:28 +0000
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cHYfz49gSOqQaz0MIEGwb+ihVN3jU3PE1RUTwC3b6M1+qR/r5r7n2NIVbmH+9uaHg1g7JItp2c20v9Tfx6TzE5eP112gsC9sdrUbZjYsaAmQsLtqXvSeKgvsh7CQGD8Cs0Eo+WHicfOwAfNyncDirwyhGHgMupstEl5zSG3AGZ0=
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!).
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.
> equinox-dev mailing list