Home » Eclipse Projects » Equinox » Equinox OSGi VS Spring ?
| Equinox OSGi VS Spring ? [message #50443] |
Tue, 11 October 2005 18:31  |
Eclipse User |
|
|
|
Originally posted by: nospam.nospam.no
I am investigating different choices for the architecual backbone of a
software system, some of it GUI, some of it non-GUI.
The spring framework is one choice with it's support for inversion of
control / dependency injection with an external xml configuration. Equinox
OSGi with its (new) support for non-GUI components seems to be another
choice.
In my view the spring framework seems to be competing with Equinox OSGi ???
What do you all think? What are the benefits/drawbacks of Equinox VS Spring
?
Thanks,
Morten Ch.
|
|
|
| Re: Equinox OSGi VS Spring ? [message #50471 is a reply to message #50443] |
Wed, 12 October 2005 06:04  |
 Eugene Ostroukhov
Messages: 66
Registered: July 2009 |
Member |
|
|
They can hardly be compared. Equinox is a plugin framework - for managing
plugins with dynamic loading/unloading, classes loader managers (each bundle
has its own classpath), etc.
Spring framework is an dependency injection framework and a set of general
purpose helper libraries (JDBC support, Hibernate, etc.)
I.e. Equinox does not have the support of dependency injection - your code
need to pick the contributions itself while the spring will configure the
beans for you. But, AFAIK, Spring will not change your application
configuration if the config file was changed at a runtime. Spring does not
break up your application in modules (like an Equinox plugins or bundles)
with private classpathes and strict set of inter-module dependencies.
I could be wrong as I'm working mostly on Eclipse plugins lately and I don't
follow the Spring development.
Eugene
"MortenCh" <nospam@nospam.no> wrote in message
news:dih0d7$6r4$1@news.eclipse.org...
>I am investigating different choices for the architecual backbone of a
>software system, some of it GUI, some of it non-GUI.
>
> The spring framework is one choice with it's support for inversion of
> control / dependency injection with an external xml configuration. Equinox
> OSGi with its (new) support for non-GUI components seems to be another
> choice.
>
> In my view the spring framework seems to be competing with Equinox OSGi
> ??? What do you all think? What are the benefits/drawbacks of Equinox VS
> Spring ?
>
> Thanks,
> Morten Ch.
>
|
|
|
| Re: Equinox OSGi VS Spring ? [message #50555 is a reply to message #50443] |
Fri, 14 October 2005 20:31 |
| Eclipse User |
|
|
|
Originally posted by: mikhail_kimmelman.hotmail.com
"MortenCh" <nospam@nospam.no> wrote in message
news:dih0d7$6r4$1@news.eclipse.org...
> In my view the spring framework seems to be competing with Equinox OSGi
> ??? What do you all think? What are the benefits/drawbacks of Equinox VS
> Spring ?
I am also new at all of this and trying to think about the same problems.
Let's assume I have 3 components A, B, and C with interfaces
IA, IB and IC and implementation classes AImpl, BImpl and CImpl
respectively. Let's assume that A depends on B and B depends on C.
In order to replace the components implemenations transparently
we want the components to know only the interfaces (rather than
the implementation classes). How would we solve it Spring and OSGi ?
In Spring we define all those components along with their interfaces,
implementation
classes and dependencies in a single XML.
A component client uses a Spring API to get a component by name.
The API instantiates the component implementation class and resolves
dependencies
using the XML definitions.
In OSGi we create a bundle for each component, define the interfaces as
exported
and imported services, and write a BundleActivator class for each component
to resolve dependencies using OSGi API.
A component client is also a bundle, which gets a service via its
BundleActivator.
Misha
P.S. In the next message I will try to formulate pros and cons of these
solutions.
|
|
|
| Re: Equinox OSGi VS Spring ? [message #50583 is a reply to message #50555] |
Sat, 15 October 2005 15:41 |
| Eclipse User |
|
|
|
Originally posted by: nospam.nospam.no
Hi Mikhail Kimmelman,
Thanks for your reply. It is nice to see others thinking of OSGi vs Spring
too. As to pros/cons: Basically I see the Spring component model as very
lightweight while OSGi is heavy yet more powerful like enabling
activation/deactivation at runtime. OSGi tightly couples ones components to
OSGi, while Spring has no/little coupling so it it easier to replace Spring
in the future.
Cheers,
Morten
"Mikhail Kimmelman" <mikhail_kimmelman@hotmail.com> wrote in message
news:dip4e2$ack$1@news.eclipse.org...
>
> "MortenCh" <nospam@nospam.no> wrote in message
> news:dih0d7$6r4$1@news.eclipse.org...
>
>> In my view the spring framework seems to be competing with Equinox OSGi
>> ??? What do you all think? What are the benefits/drawbacks of Equinox VS
>> Spring ?
>
> I am also new at all of this and trying to think about the same problems.
>
> Let's assume I have 3 components A, B, and C with interfaces
> IA, IB and IC and implementation classes AImpl, BImpl and CImpl
> respectively. Let's assume that A depends on B and B depends on C.
>
> In order to replace the components implemenations transparently
> we want the components to know only the interfaces (rather than
> the implementation classes). How would we solve it Spring and OSGi ?
>
> In Spring we define all those components along with their interfaces,
> implementation
> classes and dependencies in a single XML.
>
> A component client uses a Spring API to get a component by name.
> The API instantiates the component implementation class and resolves
> dependencies
> using the XML definitions.
>
> In OSGi we create a bundle for each component, define the interfaces as
> exported
> and imported services, and write a BundleActivator class for each
> component
> to resolve dependencies using OSGi API.
>
> A component client is also a bundle, which gets a service via its
> BundleActivator.
>
> Misha
>
> P.S. In the next message I will try to formulate pros and cons of these
> solutions.
|
|
|
| Re: Equinox OSGi VS Spring ? [message #50611 is a reply to message #50583] |
Sat, 15 October 2005 17:36 |
| Eclipse User |
|
|
|
Originally posted by: mikhail_kimmelman.hotmail.com
"MortenCh" <nospam@nospam.no> wrote in message
news:dir7un$c19$1@news.eclipse.org...
> Hi Mikhail Kimmelman,
Hi Morten (it is your first name, isn't it ?)
> Thanks for your reply. It is nice to see others thinking of OSGi vs Spring
> too.
:)
> As to pros/cons: Basically I see the Spring component model as very
> lightweight while OSGi is heavy yet more powerful like enabling
> activation/deactivation at runtime.
I basically agree.
As for activation/deactivation in runtime, I do not know if I need it.
In server apps we defintely need update components in runtime
but ejb containers already provide such a feature.
Do we need it in desktop applications ? I do not know.
I wonder if Eclipse does really need it.
> OSGi tightly couples ones components to OSGi,
I do not agree. It depends on how you design your component.
As I understand OSGi allows you to clearly separate business components
and OSGi stuff (such as BundleActivators, etc.).
For instance, BundleActivator may instantiate a component, look up its
dependencies in the BundleContext and plug them into the component.
In this scenario the component does not know about OSGi at all.
> while Spring has no/little coupling so it it easier to replace Spring in
> the future.
I partially agree. The component code does not depend on Spring
but the metadata do. If you abandon Spring you cannot reuse the metadata.
I would say that both Spring and OSGi allows reasonably loose coupling
between business components and infrastructure.
Spring provides more automation (see constructor dependency injection)
and relies mostly on metadata. OSGi forces you to write glue code
(e.g. BundleActivator) manually.
Misha
|
|
|
| Re: Equinox OSGi VS Spring ? [message #50693 is a reply to message #50611] |
Sun, 16 October 2005 18:52 |
| Eclipse User |
|
|
|
Originally posted by: khan.tasinga.gmail.com
Hello Misha, Morten,
This is an interesting thread. I'm far from either a Spring
or Equinox expert. But, I just started flipping through the
recently released OSGi R4 specification (with which Equinox
just announced compliant), and wanted to chime in.
Specifically, I wanted to bring-up the 'Declarative Services'
portion of the specification. From what I've read, it basically
grew out of the OSGi Service Binder project (discussed here:
http://gravity.sourceforge.net/servicebinder/), and is geared
towards doing what Spring does (ie. minimizing / eliminating
the code developers have to write for dependency management).
I don't know if it's something you folks would be interested
in checking-out, but I figured I'd just go ahead and mention
it anyway ;).
Regards,
Khan MT
Mikhail Kimmelman wrote:
>
> "MortenCh" <nospam@nospam.no> wrote in message
> news:dir7un$c19$1@news.eclipse.org...
>
>> Hi Mikhail Kimmelman,
>
>
> Hi Morten (it is your first name, isn't it ?)
>
>> Thanks for your reply. It is nice to see others thinking of OSGi vs
>> Spring
>> too.
>
>
> :)
>
>> As to pros/cons: Basically I see the Spring component model as very
>> lightweight while OSGi is heavy yet more powerful like enabling
>> activation/deactivation at runtime.
>
>
> I basically agree.
>
> As for activation/deactivation in runtime, I do not know if I need it.
> In server apps we defintely need update components in runtime
> but ejb containers already provide such a feature.
> Do we need it in desktop applications ? I do not know.
> I wonder if Eclipse does really need it.
>
>> OSGi tightly couples ones components to OSGi,
>
>
> I do not agree. It depends on how you design your component.
> As I understand OSGi allows you to clearly separate business components
> and OSGi stuff (such as BundleActivators, etc.).
>
> For instance, BundleActivator may instantiate a component, look up its
> dependencies in the BundleContext and plug them into the component.
> In this scenario the component does not know about OSGi at all.
>
>> while Spring has no/little coupling so it it easier to replace Spring in
>> the future.
>
>
> I partially agree. The component code does not depend on Spring
> but the metadata do. If you abandon Spring you cannot reuse the metadata.
>
> I would say that both Spring and OSGi allows reasonably loose coupling
> between business components and infrastructure.
>
> Spring provides more automation (see constructor dependency injection)
> and relies mostly on metadata. OSGi forces you to write glue code
> (e.g. BundleActivator) manually.
>
> Misha
>
|
|
|
| Re: Equinox OSGi VS Spring ? [message #51169 is a reply to message #50693] |
Thu, 20 October 2005 23:05 |
Jeremy Volkman
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
They can compliment each other. I was messing around with ServiceBinder
and hacked together a Spring/ServiceBinder integration better detailed
here:
http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev /200509.mbox/<dccc2ca905092914039c4c1e0%40mail.gmail.com>
With this solution, instead of giving ServiceBinder a class-type to hand
off as a service, you give it a Spring bean, and let Spring take care of
instantiating the service bean.
Jeremy Volkman
Khan Tasinga wrote:
> Hello Misha, Morten,
> This is an interesting thread. I'm far from either a Spring
> or Equinox expert. But, I just started flipping through the
> recently released OSGi R4 specification (with which Equinox
> just announced compliant), and wanted to chime in.
> Specifically, I wanted to bring-up the 'Declarative Services'
> portion of the specification. From what I've read, it basically
> grew out of the OSGi Service Binder project (discussed here:
> http://gravity.sourceforge.net/servicebinder/), and is geared
> towards doing what Spring does (ie. minimizing / eliminating
> the code developers have to write for dependency management).
> I don't know if it's something you folks would be interested
> in checking-out, but I figured I'd just go ahead and mention
> it anyway ;).
> Regards,
> Khan MT
> Mikhail Kimmelman wrote:
>>
>> "MortenCh" <nospam@nospam.no> wrote in message
>> news:dir7un$c19$1@news.eclipse.org...
>>
>>> Hi Mikhail Kimmelman,
>>
>>
>> Hi Morten (it is your first name, isn't it ?)
>>
>>> Thanks for your reply. It is nice to see others thinking of OSGi vs
>>> Spring
>>> too.
>>
>>
>> :)
>>
>>> As to pros/cons: Basically I see the Spring component model as very
>>> lightweight while OSGi is heavy yet more powerful like enabling
>>> activation/deactivation at runtime.
>>
>>
>> I basically agree.
>>
>> As for activation/deactivation in runtime, I do not know if I need it.
>> In server apps we defintely need update components in runtime
>> but ejb containers already provide such a feature.
>> Do we need it in desktop applications ? I do not know.
>> I wonder if Eclipse does really need it.
>>
>>> OSGi tightly couples ones components to OSGi,
>>
>>
>> I do not agree. It depends on how you design your component.
>> As I understand OSGi allows you to clearly separate business components
>> and OSGi stuff (such as BundleActivators, etc.).
>>
>> For instance, BundleActivator may instantiate a component, look up its
>> dependencies in the BundleContext and plug them into the component.
>> In this scenario the component does not know about OSGi at all.
>>
>>> while Spring has no/little coupling so it it easier to replace Spring in
>>> the future.
>>
>>
>> I partially agree. The component code does not depend on Spring
>> but the metadata do. If you abandon Spring you cannot reuse the metadata.
>>
>> I would say that both Spring and OSGi allows reasonably loose coupling
>> between business components and infrastructure.
>>
>> Spring provides more automation (see constructor dependency injection)
>> and relies mostly on metadata. OSGi forces you to write glue code
>> (e.g. BundleActivator) manually.
>>
>> Misha
>>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 23:26:58 GMT 2024
Powered by FUDForum. Page generated in 0.03326 seconds |
] 
Search
Help
Register
Login
Home
