Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Please support Spring in e4
Please support Spring in e4 [message #844] Fri, 17 July 2009 07:18 Go to next message
Eclipse UserFriend
Originally posted by: dankof.abis-reicom.de

Hello,

I just read that one of the main goals for e4 will be to provide IoC capability. I'd like
to propose that this should include compatibility with Spring/Spring DM. Spring
ist widely used and therefore it could be nice to have an integration.

Is there anyone supporting my opinion?
Re: Please support Spring in e4 [message #874 is a reply to message #844] Fri, 17 July 2009 07:44 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hi,

What do you mean with compability with SpringDM would does that mean? We
are use Constructor and Method DI (with custom Annontations). So what
would you expect to be possible?

Tom

Fabian Dankof schrieb:
> Hello,
>
> I just read that one of the main goals for e4 will be to provide IoC capability. I'd like
> to propose that this should include compatibility with Spring/Spring DM. Spring
> ist widely used and therefore it could be nice to have an integration.
>
> Is there anyone supporting my opinion?
Re: Re: Please support Spring in e4 [message #904 is a reply to message #874] Fri, 17 July 2009 08:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dankof.abis-reicom.de

I'd like to be able to configure DI with Spring Spring (or more precisely: Spring Dynamic Modules for OSGi) as it has very neat support for OSGi services:

* OSGi Services can be used in a declarative manner (no code except setters)
* Spring queues calls for an OSGi service (no need to check if service has gone or isn't yet available)

I think the following scenarios should be possible:

Declare a command with a commandID and use this commandID in a Spring bean config as identifier for a command bean.

e.g.: <bean id="my.id.from.plugin.xml" class="foo.command1" />

Same with editors, views, etc. so that it will be possible to use those nice spring features like service call queueing.
Re: Please support Spring in e4 [message #934 is a reply to message #904] Fri, 17 July 2009 12:49 Go to previous messageGo to next message
Chris Aniszczyk is currently offline Chris AniszczykFriend
Messages: 674
Registered: July 2009
Senior Member
Fabian Dankof wrote:
> I'd like to be able to configure DI with Spring Spring (or more precisely: Spring Dynamic Modules for OSGi) as it has very neat support for OSGi services:
>
> * OSGi Services can be used in a declarative manner (no code except setters)
> * Spring queues calls for an OSGi service (no need to check if service has gone or isn't yet available)
>
> I think the following scenarios should be possible:
>
> Declare a command with a commandID and use this commandID in a Spring bean config as identifier for a command bean.
>
> e.g.: <bean id="my.id.from.plugin.xml" class="foo.command1" />
>
> Same with editors, views, etc. so that it will be possible to use those nice spring features like service call queueing.

Please note that there are many ways to declaratively work with OSGi
services. One standard way is OSGi Declarative Services which ships with
Eclipse already (as of the Galileo release). We even have tooling. DS is
VERY lightweight.

There's iPojo if you like to try the annotation route.

There's also the upcoming OSGi Blueprint service which is loosely based
on SpringDM concepts...

http://gnodet.blogspot.com/2009/06/osgi-blueprint-services.h tml

Also note, not everyone uses Spring...

Cheers,

Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
Re: Please support Spring in e4 [message #964 is a reply to message #934] Fri, 17 July 2009 13:52 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hi,

Please correct me when I'm wrong but IIRC stuff like Spring, OSGi-DS
expects that it controls the lifecylce of the Component it is injects
stuff into.

The problem with injecting into UI-Components like Editors/Views is that
the lifecycle has to be control by the Eclipse-Workbench and can't be
moved to some external party.

In E4 the IEclipseContext acts as a mediator between the UI with its
lifecycle and the services and their lifecycle. If I understood the
presentation from John Arthone at EclipseCon appropriately one gets
access to OSGi-Services directly through the IEclipseContext but Boris
and/or John could explain this better than me.

Tom

Chris Aniszczyk schrieb:
> Fabian Dankof wrote:
>> I'd like to be able to configure DI with Spring Spring (or more
>> precisely: Spring Dynamic Modules for OSGi) as it has very neat
>> support for OSGi services:
>>
>> * OSGi Services can be used in a declarative manner (no code except
>> setters)
>> * Spring queues calls for an OSGi service (no need to check if service
>> has gone or isn't yet available)
>>
>> I think the following scenarios should be possible:
>>
>> Declare a command with a commandID and use this commandID in a Spring
>> bean config as identifier for a command bean.
>>
>> e.g.: <bean id="my.id.from.plugin.xml" class="foo.command1" />
>>
>> Same with editors, views, etc. so that it will be possible to use
>> those nice spring features like service call queueing.
>
> Please note that there are many ways to declaratively work with OSGi
> services. One standard way is OSGi Declarative Services which ships with
> Eclipse already (as of the Galileo release). We even have tooling. DS is
> VERY lightweight.
>
> There's iPojo if you like to try the annotation route.
>
> There's also the upcoming OSGi Blueprint service which is loosely based
> on SpringDM concepts...
>
> http://gnodet.blogspot.com/2009/06/osgi-blueprint-services.h tml
>
> Also note, not everyone uses Spring...
>
> Cheers,
>
> Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
> http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
Re: Re: Please support Spring in e4 [message #993 is a reply to message #964] Mon, 20 July 2009 14:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dankof.abis-reicom.de

Hi,

I wasn't aware of other declarative frameworks for OSGi. In essence, what I was going to say is
that using OSGi services should be simpler in e4. At the moment I'm working with Eclipse 3.4. Using
an OSGi service requires a lot of error checking (timeouts, service disappeared, ...) which just feels
unnecessary if you used Spring-DM once.

So forget about declaring Editors/Views in Spring - if Eclipse would have easier OSGi service support
that would do the trick.

Greets,

Fabian
Re: Please support Spring in e4 [message #1022 is a reply to message #993] Fri, 24 July 2009 20:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: eclipseng.arthorne.com

Fabian Dankof wrote:
> So forget about declaring Editors/Views in Spring - if Eclipse would have easier OSGi service support
> that would do the trick.

e4 has service injection into user objects much like Spring, so I think
you will be happy. Also the e4 context mechanism has a pluggable service
lookup strategy that might be able to act as a bridge to a Spring
module, although I don't know if anyone has tried this.
--
Re: Please support Spring in e4 [message #1047 is a reply to message #1022] Sat, 25 July 2009 11:37 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 113
Registered: July 2009
Senior Member
I think there are a couple of aspects around using Spring in this:

a) Spring DM - nothing should prohibit the use of this since its all
OSGi. Note that spring DM typically starts before (but is not guaranteed
to be) other bundles and that it loads contexts for already active
bundles and then listens for other bundles activations. If it starts
before some of the eclipse bundles, some of the eclipse components may
not be fully initialized. One example is the realm, where you may have
to stub it out with your own instead of trying to use the one based on
the display default. In other words, you have to be careful about
dependencies in spring dm--no surprise of course.

b) Spring to create other contexts with objects. This will probably
work. Most likely, you can still create eclipse components in contexts
as you can with 3.5 and before. You'll have to have the right hooks
though since, as the other posts point out, you have to understand
lifecycle. For example, in 3.5, you can use an ExtensionFactory concept
to tie into your spring context to grab editors, views, etc. I use
spring contexts today to create daos, label and content providers and
other objects that are displayed in a common navigator hierarchically
and they all tie into a hierarchical set of contexts representing by
application domain. I just type the name of the object in the extension
and it is automatically found in the right context at the right level in
the navigator tree and I get DI to handle DAOs and other stuff needed to
power the label and content providers.

Because a baseline DI framework has to be established for eclipse so
something works out of the box and you can depend on it, I don't think
you can just swap the DI layer 100%, but I think you'll want to ensure
that for both spring dm and standard spring contexts, you can tie them
in without too much glue. I'll vote for that. For example, the ability
to have pojos defined in your own spring context that is plugged into
IEclipseContexts lookup method. The new WPF-based reference application
framework does this. In essence, the IEclipseContext has its own
mechanism but also other lookup "providers" that can be added to find
objects and you just add your context as a lookup provider. I'll look
into the pluggable service lookup strategy that John mentions.

While I am casting my "vote," I would also vote for an event
broadcasting system as a service. It makes letting different parts of
your GUI know what is happening in other parts of your application alot
easier. You could also rebuild the ICommand/IHandler system on top of it.


John Arthorne wrote:
> Fabian Dankof wrote:
>> So forget about declaring Editors/Views in Spring - if Eclipse would
>> have easier OSGi service support
>> that would do the trick.
>
> e4 has service injection into user objects much like Spring, so I think
> you will be happy. Also the e4 context mechanism has a pluggable service
> lookup strategy that might be able to act as a bridge to a Spring
> module, although I don't know if anyone has tried this.
> --
Re: Please support Spring in e4 [message #1075 is a reply to message #1047] Sat, 25 July 2009 11:51 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 113
Registered: July 2009
Senior Member
I did look at the context services and it looks like adding the lookup
"provider" strategy is doable. However, where in the code does the
context get set for the toplevel context? The static factory looks
hardwired into the workbench object and if this was settable, say in the
plugin.xml or something like that, we could inject it into the
workbench. Can the toplevel workbench be injected (or advised?) or can
one specify the factory that is used at the workbench level?

One request is to be able to iterate through all objects defined in the
context by providing a method or expose an iterator property. This may
be too big of an API burden though on implementations.


aappddeevv wrote:
> I think there are a couple of aspects around using Spring in this:
>
> a) Spring DM - nothing should prohibit the use of this since its all
> OSGi. Note that spring DM typically starts before (but is not guaranteed
> to be) other bundles and that it loads contexts for already active
> bundles and then listens for other bundles activations. If it starts
> before some of the eclipse bundles, some of the eclipse components may
> not be fully initialized. One example is the realm, where you may have
> to stub it out with your own instead of trying to use the one based on
> the display default. In other words, you have to be careful about
> dependencies in spring dm--no surprise of course.
>
> b) Spring to create other contexts with objects. This will probably
> work. Most likely, you can still create eclipse components in contexts
> as you can with 3.5 and before. You'll have to have the right hooks
> though since, as the other posts point out, you have to understand
> lifecycle. For example, in 3.5, you can use an ExtensionFactory concept
> to tie into your spring context to grab editors, views, etc. I use
> spring contexts today to create daos, label and content providers and
> other objects that are displayed in a common navigator hierarchically
> and they all tie into a hierarchical set of contexts representing by
> application domain. I just type the name of the object in the extension
> and it is automatically found in the right context at the right level in
> the navigator tree and I get DI to handle DAOs and other stuff needed to
> power the label and content providers.
>
> Because a baseline DI framework has to be established for eclipse so
> something works out of the box and you can depend on it, I don't think
> you can just swap the DI layer 100%, but I think you'll want to ensure
> that for both spring dm and standard spring contexts, you can tie them
> in without too much glue. I'll vote for that. For example, the ability
> to have pojos defined in your own spring context that is plugged into
> IEclipseContexts lookup method. The new WPF-based reference application
> framework does this. In essence, the IEclipseContext has its own
> mechanism but also other lookup "providers" that can be added to find
> objects and you just add your context as a lookup provider. I'll look
> into the pluggable service lookup strategy that John mentions.
>
> While I am casting my "vote," I would also vote for an event
> broadcasting system as a service. It makes letting different parts of
> your GUI know what is happening in other parts of your application alot
> easier. You could also rebuild the ICommand/IHandler system on top of it.
>
>
> John Arthorne wrote:
>> Fabian Dankof wrote:
>>> So forget about declaring Editors/Views in Spring - if Eclipse would
>>> have easier OSGi service support
>>> that would do the trick.
>>
>> e4 has service injection into user objects much like Spring, so I
>> think you will be happy. Also the e4 context mechanism has a pluggable
>> service lookup strategy that might be able to act as a bridge to a
>> Spring module, although I don't know if anyone has tried this.
>> --
Re: Please support Spring in e4 [message #442612 is a reply to message #993] Fri, 31 July 2009 13:14 Go to previous message
No real name is currently offline No real nameFriend
Messages: 113
Registered: July 2009
Senior Member
While I am not an involved developer, a patch has been submitted that
allows various ways to use spring contexts. First, OSGi services defined
by spring are available already, but a second way, by making the context
creation process an OSGi service and also making context creation a
service itself in the context, is also available.
Re: Please support Spring in e4 [message #561479 is a reply to message #844] Fri, 17 July 2009 07:44 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hi,

What do you mean with compability with SpringDM would does that mean? We
are use Constructor and Method DI (with custom Annontations). So what
would you expect to be possible?

Tom

Fabian Dankof schrieb:
> Hello,
>
> I just read that one of the main goals for e4 will be to provide IoC capability. I'd like
> to propose that this should include compatibility with Spring/Spring DM. Spring
> ist widely used and therefore it could be nice to have an integration.
>
> Is there anyone supporting my opinion?
Re: Re: Please support Spring in e4 [message #561500 is a reply to message #874] Fri, 17 July 2009 08:20 Go to previous message
Fabian Dankof is currently offline Fabian DankofFriend
Messages: 9
Registered: July 2009
Junior Member
I'd like to be able to configure DI with Spring Spring (or more precisely: Spring Dynamic Modules for OSGi) as it has very neat support for OSGi services:

* OSGi Services can be used in a declarative manner (no code except setters)
* Spring queues calls for an OSGi service (no need to check if service has gone or isn't yet available)

I think the following scenarios should be possible:

Declare a command with a commandID and use this commandID in a Spring bean config as identifier for a command bean.

e.g.: <bean id="my.id.from.plugin.xml" class="foo.command1" />

Same with editors, views, etc. so that it will be possible to use those nice spring features like service call queueing.
Re: Please support Spring in e4 [message #561520 is a reply to message #904] Fri, 17 July 2009 12:49 Go to previous message
Chris Aniszczyk is currently offline Chris AniszczykFriend
Messages: 674
Registered: July 2009
Senior Member
Fabian Dankof wrote:
> I'd like to be able to configure DI with Spring Spring (or more precisely: Spring Dynamic Modules for OSGi) as it has very neat support for OSGi services:
>
> * OSGi Services can be used in a declarative manner (no code except setters)
> * Spring queues calls for an OSGi service (no need to check if service has gone or isn't yet available)
>
> I think the following scenarios should be possible:
>
> Declare a command with a commandID and use this commandID in a Spring bean config as identifier for a command bean.
>
> e.g.: <bean id="my.id.from.plugin.xml" class="foo.command1" />
>
> Same with editors, views, etc. so that it will be possible to use those nice spring features like service call queueing.

Please note that there are many ways to declaratively work with OSGi
services. One standard way is OSGi Declarative Services which ships with
Eclipse already (as of the Galileo release). We even have tooling. DS is
VERY lightweight.

There's iPojo if you like to try the annotation route.

There's also the upcoming OSGi Blueprint service which is loosely based
on SpringDM concepts...

http://gnodet.blogspot.com/2009/06/osgi-blueprint-services.h tml

Also note, not everyone uses Spring...

Cheers,

Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
Re: Please support Spring in e4 [message #561536 is a reply to message #934] Fri, 17 July 2009 13:52 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hi,

Please correct me when I'm wrong but IIRC stuff like Spring, OSGi-DS
expects that it controls the lifecylce of the Component it is injects
stuff into.

The problem with injecting into UI-Components like Editors/Views is that
the lifecycle has to be control by the Eclipse-Workbench and can't be
moved to some external party.

In E4 the IEclipseContext acts as a mediator between the UI with its
lifecycle and the services and their lifecycle. If I understood the
presentation from John Arthone at EclipseCon appropriately one gets
access to OSGi-Services directly through the IEclipseContext but Boris
and/or John could explain this better than me.

Tom

Chris Aniszczyk schrieb:
> Fabian Dankof wrote:
>> I'd like to be able to configure DI with Spring Spring (or more
>> precisely: Spring Dynamic Modules for OSGi) as it has very neat
>> support for OSGi services:
>>
>> * OSGi Services can be used in a declarative manner (no code except
>> setters)
>> * Spring queues calls for an OSGi service (no need to check if service
>> has gone or isn't yet available)
>>
>> I think the following scenarios should be possible:
>>
>> Declare a command with a commandID and use this commandID in a Spring
>> bean config as identifier for a command bean.
>>
>> e.g.: <bean id="my.id.from.plugin.xml" class="foo.command1" />
>>
>> Same with editors, views, etc. so that it will be possible to use
>> those nice spring features like service call queueing.
>
> Please note that there are many ways to declaratively work with OSGi
> services. One standard way is OSGi Declarative Services which ships with
> Eclipse already (as of the Galileo release). We even have tooling. DS is
> VERY lightweight.
>
> There's iPojo if you like to try the annotation route.
>
> There's also the upcoming OSGi Blueprint service which is loosely based
> on SpringDM concepts...
>
> http://gnodet.blogspot.com/2009/06/osgi-blueprint-services.h tml
>
> Also note, not everyone uses Spring...
>
> Cheers,
>
> Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
> http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
Re: Re: Please support Spring in e4 [message #561555 is a reply to message #964] Mon, 20 July 2009 14:07 Go to previous message
Fabian Dankof is currently offline Fabian DankofFriend
Messages: 9
Registered: July 2009
Junior Member
Hi,

I wasn't aware of other declarative frameworks for OSGi. In essence, what I was going to say is
that using OSGi services should be simpler in e4. At the moment I'm working with Eclipse 3.4. Using
an OSGi service requires a lot of error checking (timeouts, service disappeared, ...) which just feels
unnecessary if you used Spring-DM once.

So forget about declaring Editors/Views in Spring - if Eclipse would have easier OSGi service support
that would do the trick.

Greets,

Fabian
Re: Please support Spring in e4 [message #561576 is a reply to message #993] Fri, 24 July 2009 20:38 Go to previous message
John Arthorne is currently offline John ArthorneFriend
Messages: 176
Registered: July 2009
Senior Member
Fabian Dankof wrote:
> So forget about declaring Editors/Views in Spring - if Eclipse would have easier OSGi service support
> that would do the trick.

e4 has service injection into user objects much like Spring, so I think
you will be happy. Also the e4 context mechanism has a pluggable service
lookup strategy that might be able to act as a bridge to a Spring
module, although I don't know if anyone has tried this.
--
Re: Please support Spring in e4 [message #561594 is a reply to message #1022] Sat, 25 July 2009 11:37 Go to previous message
No real name is currently offline No real nameFriend
Messages: 113
Registered: July 2009
Senior Member
I think there are a couple of aspects around using Spring in this:

a) Spring DM - nothing should prohibit the use of this since its all
OSGi. Note that spring DM typically starts before (but is not guaranteed
to be) other bundles and that it loads contexts for already active
bundles and then listens for other bundles activations. If it starts
before some of the eclipse bundles, some of the eclipse components may
not be fully initialized. One example is the realm, where you may have
to stub it out with your own instead of trying to use the one based on
the display default. In other words, you have to be careful about
dependencies in spring dm--no surprise of course.

b) Spring to create other contexts with objects. This will probably
work. Most likely, you can still create eclipse components in contexts
as you can with 3.5 and before. You'll have to have the right hooks
though since, as the other posts point out, you have to understand
lifecycle. For example, in 3.5, you can use an ExtensionFactory concept
to tie into your spring context to grab editors, views, etc. I use
spring contexts today to create daos, label and content providers and
other objects that are displayed in a common navigator hierarchically
and they all tie into a hierarchical set of contexts representing by
application domain. I just type the name of the object in the extension
and it is automatically found in the right context at the right level in
the navigator tree and I get DI to handle DAOs and other stuff needed to
power the label and content providers.

Because a baseline DI framework has to be established for eclipse so
something works out of the box and you can depend on it, I don't think
you can just swap the DI layer 100%, but I think you'll want to ensure
that for both spring dm and standard spring contexts, you can tie them
in without too much glue. I'll vote for that. For example, the ability
to have pojos defined in your own spring context that is plugged into
IEclipseContexts lookup method. The new WPF-based reference application
framework does this. In essence, the IEclipseContext has its own
mechanism but also other lookup "providers" that can be added to find
objects and you just add your context as a lookup provider. I'll look
into the pluggable service lookup strategy that John mentions.

While I am casting my "vote," I would also vote for an event
broadcasting system as a service. It makes letting different parts of
your GUI know what is happening in other parts of your application alot
easier. You could also rebuild the ICommand/IHandler system on top of it.


John Arthorne wrote:
> Fabian Dankof wrote:
>> So forget about declaring Editors/Views in Spring - if Eclipse would
>> have easier OSGi service support
>> that would do the trick.
>
> e4 has service injection into user objects much like Spring, so I think
> you will be happy. Also the e4 context mechanism has a pluggable service
> lookup strategy that might be able to act as a bridge to a Spring
> module, although I don't know if anyone has tried this.
> --
Re: Please support Spring in e4 [message #561611 is a reply to message #1047] Sat, 25 July 2009 11:51 Go to previous message
No real name is currently offline No real nameFriend
Messages: 113
Registered: July 2009
Senior Member
I did look at the context services and it looks like adding the lookup
"provider" strategy is doable. However, where in the code does the
context get set for the toplevel context? The static factory looks
hardwired into the workbench object and if this was settable, say in the
plugin.xml or something like that, we could inject it into the
workbench. Can the toplevel workbench be injected (or advised?) or can
one specify the factory that is used at the workbench level?

One request is to be able to iterate through all objects defined in the
context by providing a method or expose an iterator property. This may
be too big of an API burden though on implementations.


aappddeevv wrote:
> I think there are a couple of aspects around using Spring in this:
>
> a) Spring DM - nothing should prohibit the use of this since its all
> OSGi. Note that spring DM typically starts before (but is not guaranteed
> to be) other bundles and that it loads contexts for already active
> bundles and then listens for other bundles activations. If it starts
> before some of the eclipse bundles, some of the eclipse components may
> not be fully initialized. One example is the realm, where you may have
> to stub it out with your own instead of trying to use the one based on
> the display default. In other words, you have to be careful about
> dependencies in spring dm--no surprise of course.
>
> b) Spring to create other contexts with objects. This will probably
> work. Most likely, you can still create eclipse components in contexts
> as you can with 3.5 and before. You'll have to have the right hooks
> though since, as the other posts point out, you have to understand
> lifecycle. For example, in 3.5, you can use an ExtensionFactory concept
> to tie into your spring context to grab editors, views, etc. I use
> spring contexts today to create daos, label and content providers and
> other objects that are displayed in a common navigator hierarchically
> and they all tie into a hierarchical set of contexts representing by
> application domain. I just type the name of the object in the extension
> and it is automatically found in the right context at the right level in
> the navigator tree and I get DI to handle DAOs and other stuff needed to
> power the label and content providers.
>
> Because a baseline DI framework has to be established for eclipse so
> something works out of the box and you can depend on it, I don't think
> you can just swap the DI layer 100%, but I think you'll want to ensure
> that for both spring dm and standard spring contexts, you can tie them
> in without too much glue. I'll vote for that. For example, the ability
> to have pojos defined in your own spring context that is plugged into
> IEclipseContexts lookup method. The new WPF-based reference application
> framework does this. In essence, the IEclipseContext has its own
> mechanism but also other lookup "providers" that can be added to find
> objects and you just add your context as a lookup provider. I'll look
> into the pluggable service lookup strategy that John mentions.
>
> While I am casting my "vote," I would also vote for an event
> broadcasting system as a service. It makes letting different parts of
> your GUI know what is happening in other parts of your application alot
> easier. You could also rebuild the ICommand/IHandler system on top of it.
>
>
> John Arthorne wrote:
>> Fabian Dankof wrote:
>>> So forget about declaring Editors/Views in Spring - if Eclipse would
>>> have easier OSGi service support
>>> that would do the trick.
>>
>> e4 has service injection into user objects much like Spring, so I
>> think you will be happy. Also the e4 context mechanism has a pluggable
>> service lookup strategy that might be able to act as a bridge to a
>> Spring module, although I don't know if anyone has tried this.
>> --
Re: Please support Spring in e4 [message #561810 is a reply to message #993] Fri, 31 July 2009 13:14 Go to previous message
No real name is currently offline No real nameFriend
Messages: 113
Registered: July 2009
Senior Member
While I am not an involved developer, a patch has been submitted that
allows various ways to use spring contexts. First, OSGi services defined
by spring are available already, but a second way, by making the context
creation process an OSGi service and also making context creation a
service itself in the context, is also available.
Previous Topic:Modifying CSS presentation for IDE
Next Topic:Can not run demo/sample projects
Goto Forum:
  


Current Time: Thu Mar 28 20:45:00 GMT 2024

Powered by FUDForum. Page generated in 0.02969 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top