Home » Eclipse Projects » Eclipse 4 » Please support Spring in e4
| Please support Spring in e4 [message #844] |
Fri, 17 July 2009 07:18  |
Eclipse User |
|
|
|
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: Re: Please support Spring in e4 [message #904 is a reply to message #874] |
Fri, 17 July 2009 08:20  |
| Eclipse User |
|
|
|
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: Re: Please support Spring in e4 [message #993 is a reply to message #964] |
Mon, 20 July 2009 14:07 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 |
 No real name
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 |
No real name
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 #561594 is a reply to message #1022] |
Sat, 25 July 2009 11:37 |
No real name
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 |
No real name
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.
>> --
|
|
| |
Goto Forum:
Current Time: Thu Nov 21 14:42:21 GMT 2024
Powered by FUDForum. Page generated in 0.07477 seconds |
] 
Search
Help
Register
Login
Home
