Spring with Eclipse RCP anyone?

[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