Spring with Eclipse RCP anyone?

[cptechno]

Hi,

I'm interested to integrate Spring into Eclipse RCP so that the actions can be wired up automagically by Spring.

I would like to know if anyone tried this?
Or else, at least, is there any pointers for my further exploration?

TIA,
Raymond

[Martin Kersten]

I have considered to do so too. The problem is, everything in Eclipse is a contribution. So everything should be specified by the plugin.xml. 'Contributing' actions or anything like that, without using plugin.xml would violate the 'Everything is a contribution' rule(?).

I end up to specify only the domain related parts using Spring (Model and some controllers). I am also using a custom dependency injection solution (simply using marker interfaces) for injecting dependencies of contributed elements. Works well.

If you make further progress, please drop me a note.


Cheers,

Martin (Kersten)

[Keith Donald]

Martin,

I'd be interested in seeing your approach here. Could you by chance send me or post a sample of you using Eclipse RCP with Spring to connect Eclipse Actions and UI objects to middle tier services wired up using Spring?

[Martin Kersten]

I've talked about the domain related code. You can think about it, as the core you would write if you have to provide both, a Swing and a SWT GUI. You know all the domain-logic (meaning, model, commands, undo/redo, selection etc.) is wired up using Spring. There is no Eclipse related stuff configured using Spring. Eclipse's RCP code is than used to present the model and trigger the domain-logic related actions.

For example, the logic of an action is Eclipse RCP independent and therefore is part of the Spring stuff. An contributed action (contributed using plugin.xml) simply warps those domain actions, being able to trigger the action and/or provide dialogs/wizards to configure the action.

So you may think about the Eclipse RCP as a diffrent world triggering domain-behaviour and reacting to the domain-model.

It worked best to seperate both worlds using two diffrent projects. One is the client.domain (plugin-)project and the other is the client.ui plugin providing ui and connectors like content-provider.

Testing the client.domain stuff is done using plain jUnit tests (no Plugin-jUnit tests). And it should also do not require any Eclipse plug-ins. It helped alot to speed development. So the client.ui and client.domain are clearly seperated.

[Keith Donald]

I understand that; in fact, we implement a very similiar ui+domain layer strategy in Spring Rich Client, which is a rich client framework built on Swing that uses Spring for configuration and for connecting to the domain layer.

I'm interested in exactly how you did this with Eclipse RCP down to the code level; as I would consider making Eclipse RCP integration part of what we're doing with the Spring Rich effort as well.

Spring Rich is targeting Swing; no SWT/JFace there, and specifically data-centric enterprise apps. So we offer a good deal of features Eclipse RCP doesn't, but there is some overlap, too, and some opportunities to integrate. Seems like you could help us jumpstart that integration!

[Martin Kersten]

I understand that; in fact, we implement a very similiar ui+domain layer strategy in Spring Rich Client, which is a rich client framework built on Swing that uses Spring for configuration and for connecting to the domain layer.

I didn't evaluated it in depth.


I'm interested in exactly how you did this with Eclipse RCP down to the code level; as I would consider making Eclipse RCP integration part of what we're doing with the Spring Rich effort as well.

It's quite simple (like any MVC stuff). First you add some logic to the ui layer. Remove the ui-dependencies as much as possible and let it drip down to the model/controller part of the domain-layer. Thats all. There isn't much fuzz about it.

Spring Rich is targeting Swing; no SWT/JFace there, and specifically data-centric enterprise apps. So we offer a good deal of features Eclipse RCP doesn't, but there is some overlap, too, and some opportunities to integrate. Seems like you could help us jumpstart that integration!

There really isn't much to do. Mostly content-provider, actions and dialog logic are important. Also some high-level business logic needs to be utilized by the UI stuff. It's quite normal TDD going on.

If you have a question or anything you are fighting with, just ask me a certain question but in general it's like programming an UI application and think the way:"If I am also writing a Swing application, what logic would I like to reuse." That's it. Nothing more. Well beside having a undo/redo stuff etc. But this is also normal domain-layer stuff - so nothing to be excited about.

[cptechno]

So do you want to suggest that we can only use the pull approach (getApplicationContext().getBean() thing) on the actions, views, etc... we wrote for Eclipse?

This method is good, just I want to enable IoC on these "contributions" for Eclipse too.

I did looked a bit at Eclipse's source code. It seems that only Eclipse's WorkbenchAdvisor can be a customized implementation; others are not, including the factory classes for instantiating Views, Perspectives, Actions, etc.

If these factory classes are pluggable everything will be much simpler. However, it seems Eclipse is not the case.

Any ideas on this one?

Thanks again,
cptechno

[Martin Kersten]

So do you want to suggest that we can only use the pull approach (getApplicationContext().getBean() thing) on the actions, views, etc... we wrote for Eclipse?

It looks like. But providing aid for doing so, is much productive.


This method is good, just I want to enable IoC on these "contributions" for Eclipse too.

I use dependency injection using a context. The context is bound to the plugin class (and hidden).

So it ends up:

MyPlugin.injectDependencies(Object);

The context used by MyPlugin to inject the dependencies is configured using Spring. That's how everything is connected. If a view is created it injects it dependency on it's own (same for action, providers etc.) or if a contribution to an extension-point definied by MyPlugin is instanciated/initialized it gets its dependencies injected transparently by MyPlugin.

Thats how I tie all code together.


If these factory classes are pluggable everything will be much simpler. However, it seems Eclipse is not the case.

Maybe a factory can be seen like the dependency injection I use. You know creating a two parted solution. For example: you may define a view within Spring, setting the properties and also contribute a view using plugin.xml. Since the view is extended using a Spring RCP abstract view, it will look for a bean-definition and automatically set the properties like specified. For the user of this view, it would be absolutly transparent how the properties got injected.

Maybe the id's should be in sync meaning contributing the view: 'org.spring.view.MyView' and the corresponding context item being 'org.spring.view.MyView' (ergo the same). This can be also done with labels etc. Just store the values within such a Spring RCP definition object and on creation inject the properties.

This comes by the cost using additional JFace / SWT components - I think some are not intended to be subclassed anyway, so a property-injection facility must be provided anyway.

I guess this solution may be an great step forward compared to my dependency injection which also work great, anyway.

The above idea is very promessing. I guess I would like to join your subproject and provide some contribution and also comments and stuff. So I you like, I would like to join your project as a minior developer. (since the outcome of your affords seams to provide some value for me :-) )

[cptechno]

I use dependency injection using a context. The context is bound to the plugin class (and hidden).

So it ends up:
MyPlugin.injectDependencies(Object);



This should be what I'm looking for. However:

- (A bit OT) Does it mean that I can create a plugin that can intervene the instantiation of these contributions by giving them a already wired instances?
- If yes, where from Eclipse's source/javadoc should I begin to look into for me to dug deeper? I think actually this should be the ultimate starting point for writing IoC for Actions, Views, etc. with Spring.

Thanks again,
cptechno

[Martin Kersten]

- (A bit OT) Does it mean that I can create a plugin that can intervene the instantiation of these contributions by giving them a already wired instances?

You can only do this when the plugin defines the extension-point. The plugin defining the extension-point is responsible to create and instanciate every contribution to the point.

- If yes, where from Eclipse's source/javadoc should I begin to look into for me to dug deeper? I think actually this should be the ultimate starting point for writing IoC for Actions, Views, etc. with Spring.

Check out the plugin loading mechanisms. Like view, action etc. It's quite ugly code (if they havn't changed it yet). But you will learn much.


Can you give me an example of what you are planing /wanting to do. You know just a scenario like the RCP should be able to do this and that. I was also thinking about the way the components are created... .

Views by the way has some kind of init() methods. Therefore injecting dependencies there is not much of a problem. And ViewPart(s) are intended to be subclassed.

[cptechno]

Thanks very much for your advice, it seems I can see where I should go now.

What I'm going to do is very simple - make the actions' dependencies automagically satisfied when they are called from menu items, buttons, etc.

Of course, if menu bars, pull-down/pop-up menus can also be built with wrapper classes that goes to Spring it will be much better.

So it returns to the core of the question - integrating Spring's BeanFactory into Eclipse...

TIA,
cptechno

[Martin Kersten]

What I'm going to do is very simple - make the actions' dependencies automagically satisfied when they are called from menu items, buttons, etc.


I guess it is best to subclass an abstract action subclass providing a transparent way to inject those dependencies. This works well. The problem is that you do not control the contribution initialisation since this is done by eclipse.ui parts (I think).

Another side step is not to use the actions in a traditional way. I mostly like to use a Command like pattern:

ui.action-> Command -> domain actions

You know an ui.action should never find it's way into the domain layer. It produces much trouble and is mostly not logical. I tend to write my domain layer tests using junit only. Whenever I add eclipse related modules/dependencies to it, something is wrong. Mostly this will end up in cycles between your moduls since the UI couples tightly within the domain elements.


Of course, if menu bars, pull-down/pop-up menus can also be built with wrapper classes that goes to Spring it will be much better.


Go for it, it works well. If you define the extension it is best to use interfaces and handle interjection after creation but before the initialization process (not inbetween the init-phase).

So it returns to the core of the question - integrating Spring's BeanFactory into Eclipse...

The only way I know: Two parted. Once the element is created by Eclipse, it should look up for any stuff specified using Spring. So a Eclipse element should not be created/instanciated by a Spring context. It would be something like reversed responsibility. Since the UI layer should be responsible for UI elements and Eclipse is not build for being configured using Spring.

So draw a border inbetween and inject dependencies using special abstract classes or inject them internaly using Plugin.injectDependency() method.

Tip: Inject the dependencies only, if they are not set. So testing becomes easy.

[mmc]

I also find the subject of using spring with eclipse plugins / RCP applications interesting and potentially very useful (spring should "join" eclipse RCP instead of reventing the wheel as some people may be trying to do with spring RCP). I hope to hear more about using spring with eclipse plugins / RCP in the future!

[Keith Donald]

We should work to integrate with eclipse's rich client platform certainly. I would be doing this now myself if I built apps with Eclipse for a living. Currently, however, I and my customers prefer Swing solutions at this point, and Spring Rich adds a lot of value there.

I think what we've focused on in spring rich thus far is not reinvention, but innovation, and innovation that builds on standard Swing, not JFace/AWT. Swing needs simplification through appropriate, higher-level OO abstractions, and needs it bad. And many people still view Swing as "the" widget toolkit to build platform independent desktop apps in Java.

To date we've done a lot of cool things integrating Spring's IoC container into a Swing-app environment. The result? It's a lot easier to write a clean, concisely coded (and well-layered) swing app, where it was quite easy to write ugly, lengthy coded one before.

I should point out a good many of the issues we're addressing in rich client, for example: data validation, UI-to-domain model binding, and command/request workflow aren't really addressed by Eclipse's base RCP platform, anyway. There is a definite "enterprise/j2ee app" focus in spring rich client.

With all this said I definitely would LOVE to see Eclipse RCP integration on top of Spring, leveraging existing complimentary libraries of spring rich (such as the data binding stuff). But I wouldn't want to force spring rich users to HAVE to use eclipse's platform: in many cases it's just not necessary (particularly when a team already knows Swing, cares about platform independence, and doesn't want the complexity of the eclipse plugin model - yet another thing to configure...)

Keith

[jbetancourt]

Eclipse has code editors. Should now all standalone editors die on the vine or be just plug-ins into Eclipse? There may be reasons why they should, but then Eclipse starts becomming another OS in some ways.

I'd rather be able to use a plug-in into any container. So, a component that provides me with a value-add should be able to cooperate with other components that I use in certain containers, like IDEA, JEdit, Vslick, Netbeans, and so forth. This, I thought, was a major goal of the OOP hype and COM this or that.

Oh well, I guess off topic.

[Martin Kersten]

With all this said I definitely would LOVE to see Eclipse RCP integration on top of Spring, leveraging existing complimentary libraries of spring rich (such as the data binding stuff). But I wouldn't want to force spring rich users to HAVE to use eclipse's platform: in many cases it's just not necessary (particularly when a team already knows Swing, cares about platform independence, and doesn't want the complexity of the eclipse plugin model - yet another thing to configure...)

I guess no-one would like to force someone to use JFace/SWT. But after all I like it anyway. What I am dreaming about is the databinding stuff. I just want an adapter or something alike to use some of the Spring Rich stuff by utilizing Eclipse RCP.

But I guess we start to talk about unlayed eggs. We need an extense prototype or something real. You know, I guess you Spring RCP guys may provide a client demonstrating/integrating most of the of Spring RCP features, you think are horse-crazy (aka best). And then we Eclipse RCP maniacs will try to convert it using Eclipse. When this is done, we can see where to cut things and split the Spring RCP api. You know there should be something like a core-api and some special-apis for integrating it into either the Eclipse or Swing world.

Or maybe the Spring RCP project may be split up into two projects targeting the diffrent platforms by not sharing code but sharing ideas, possibilities and so on.

So the question is, is the Petclinic example that kind of comprehensive?

Maybe we should wait for a main release of the Spring RCP project before doing further talks. Sometimes things must grow a bit more to talk about. But sadly I am not the right person to judge the matureness of the Spring RCP project.

[hsteck]

I would go even further: have a base RCP library UI-independent, and a UI-dependent library tying it to the chosen UI, and make it pluggable, so if we would be able to use Spring RCP not only for Swing or Eclipse UIs, but also for XUL approaches and other UI frameworks. Right now I am evaluating Thinlet (http://thinlet.sourceforge.net), and it would help me a lot if I could leverage on APIs which are common (binding, command workflow, model, etc.), despite the UI I'd choose.

Regards,
Henrique Steckelberg

[olepaa]

Martin,

Can you describe a bit more in detail how you get access to your ApplicationContext and how you create your context?

I have tried creating the context with the ClassPathXmlApplicationContext and it can't find my applicationContext.xml. Using the getResource method from the Bundle object finds the file just fine.

I have also tried using the FileSystemXmlApplicationContext getting the file path from the Bundle object in eclipse. Using this setup Spring finds my application context, but none of the classes defined in the file.

I suspect my problems are related to the classloading scheme in eclipse, but have so far not been able to get anything to work.
Do you have any hints?
Or anyone else?

Regards
Ole P Aasen

[olepaa]

I got it... But a question for the spring team

After digging a bit into Eclipse and Spring classloading this weekend, I realised that Spring actually is quite flexible on this.

Both the BeanDefinitionReader (which is responsible for loading the bean classes) and the ClassPathResource can be set to use the classloader of an already exisiting class.

To get Spring to find my classes and resources, I extended the ClassPathXmlApplicationContext to set the beanClassLoader of the reader and to make the ClassPathResource use my classloader.

This made things work better, but then I realised that the DriverManagerDataSource also loads classes, and that it does so using the current thread classloader. So I extended this as well.

It actually turned out quite nice and small. No biggie. :-)

My question now to anyone in the Spring team, is: why the inconsistent behavior? Why do you make it possible to set the classloader for the beans, but not the classloader for the classes the beans themself has to load.

I for one would really like a bit more control over the classloader. Now I've got it in my own way, but it is a bit of a hack and depends a lot on the superclasses not changing. It would be nice to have this feature from the main distribution.

(code available on demand)
Regards
Ole P Aasen

[mubashir]

Ole,
I'm much interested in knowing how his is done code wise. I'm writing an app using eclipse RCP and I want to use spring for data and jms stuff. Please provide the code that shows how you got spring to work in an eclipse environment.
Thanks

[mjeaslea]

I too am desperate to see some sample code about using Spring from within Eclipse.

Something like a Eclipse treeview bound to an Spring model would be excellent :)

Even some basic code would be fantastic - has anyone seen any web pages with this sort of code? Any Sourceforge projects?

Cheers

[olepaa]

Sorry for the wait..

I have now published what I have done on my webpage. You can find it at: http://folk.uio.no/olepaa/spring/

Sorry to mjeaslea, I havn't got any code that binds it to a treeview yet, but I don't expect it to be to hard.

Good luck.

[mjeaslea]

Thank for posting the code, i've just downloaded it and started having a look.

What i'm wondering is the most approriate way to use the spring ApplicationContext object within my RCP product.

E.g. is it the Content Provider class in Eclipse that wraps around a set of calls to Spring?

Do you have any small samples that use the Alternative Classes you've provided?

Cheers

[cptechno]

olepaa,

The code could successfully load the config files, but all other resources required by the libraries failed to load...

My RCP is using ibatis and Spring. From the console I saw Spring could not find the SQL error code XML inside its spring.jar; the same problem happened when iBatis finding the DTD from its jar too.

Is there anyone successfully solved Eclipse's classloader problem with this AlternateClassPathXmlApplicationContext?

And BTW, I didn't use the Spring plugins; instead I have them placed at my project's lib. Is it the trick that made iBatis and Spring could not find resources from their own jar? :? Could you give me some hints on this?

TIA,
Raymond

[glenn2041]

I realise that this thread is old, but I thought I'd share a project I found for Eclipse RCP Spring integration: https://sourceforge.net/projects/eclipse-spring/

I have yet to implement it - just found it an hour ago, but it looks promising. If anyone is using it, or has a found something else, I'd appreciate your comments.

Cheers