|
|
RE: Declarative Services vs Spring: msg#00012
ide.eclipse.equinox.devel
|
Subject: |
RE: Declarative Services vs Spring |
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
Are
any Spring representitives involved in this JSR? It seems like a promising
vehicle for convergence.
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-r/Jw6+rmf7HQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
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
![Inactive hide details for "Neil Bartlett" <neil-eu3/G5jNAhBOSnsfY10OVw@xxxxxxxxxxxxxxxx>]() "Neil Bartlett" <
neil-eu3/G5jNAhBOSnsfY10OVw@xxxxxxxxxxxxxxxx>
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-r/Jw6+rmf7HQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
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-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx
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.
|
|
