Getting Started with Spring RCP

Let's familiarize ourselves with the Spring RCP. New life seems to have been blowing into this project: after almost two years of hiatus, the 1.0.0 release came out a few months ago. Let's leave aside the question about its direction and so on and, instead, let's look purely at the technology itself to see exactly what it offers. In that light, I've made available a simple plugin for NetBeans IDE that provides samples and templates to get things started. Below, I walk through a basic scenario using the plugin. However, even those who are not NetBeans users could learn a lot about Spring RCP by reading the steps in this tutorial and the explanations that accompany them.

Table of Contents

Getting Started


  1. Install the Spring RCP Tooling plugin into NetBeans IDE 6.1.

  2. In the New Project wizard (Ctrl-Shift-N), you will find a new project template:

     

  3. Complete the wizard and you have a project structure as follows:

    A brief overview of the files that you see above (be aware that if you move "richclient-application-context.xml" or "messages.properties" to any other place, or if you rename either of them, you need to update the Spring Rich Client panel in the application's Project Properties dialog box):

    File Explanation
    SimpleApp.java
    Provides the application's "main" method and launches the application
    via the Spring RCP "ApplicationLauncher" class. That class loads the
    application context XML file and the startup context XML file, where application-level concerns such as the splash screen, initialization sequences, and views are defined.
    SimpleLifecycleAdvisor.java Provides lifecycle management for the application. This class is
    registered in the application context XML file. It provides methods such
    as "onWindowOpened" and "onCommandsCreated", so that you have
    entry points to customize what happens when the application starts. (For example, you can adjust the application's size in the "onPreWindowOpen" method.)
    richclient-application-context.xml Provides the application context XML file, which configures the Spring RCP
    components and services.
    richclient-startup-context.xml Provides the startup context XML file, which defines the splash screen, but could define anything that you want to have happen specifically at startup.
    images.properties Provides the image resource. It is registered in the application context
    XML file.
    splash-screen.jpg Provides the splash screen image that is used in the startup context XML
    file.
    commands-context.xml Provides the application's commands, organized within menu bars and toolbars, and the items within them. This file is declared in the application context XML file.
    messages.properties Provides the display texts in a centralized location. For example, texts for titles and descriptions are found here.


    Note: The template also put most of the Spring RCP JARs on your application's classpath. Look in the Libraries node to see which ones are there. Potentially, more JARs could be included in the plugin as the complexity of the provided tooling increases.

     

  4. Run the application. You should see this:

4.5
Average: 4.5 (2 votes)
AttachmentSize
figure-1.png49.01 KB
figure-2.png37.15 KB
figure-3.png10.45 KB
figure-4.png24.74 KB
figure-5.png49.25 KB
figure-6.png9.61 KB
figure-7.png62.91 KB
figure-8.png22.96 KB
figure-9.png108.96 KB
figure-10.png64.77 KB
figure-11.png121.18 KB
figure-12.png25.68 KB
figure-13.png20.96 KB
figure-14.png105.25 KB
figure-15.png3.28 KB
figure-16.png6.23 KB
figure-17.png94.77 KB
figure-18.png80.02 KB
figure-19.png26.8 KB
figure-20.png24.82 KB
figure-21.png2.76 KB
figure-22.png9.17 KB
figure-23.png98.88 KB
figure-24.png99.05 KB
figure-25.png117.51 KB
figure-26.png99.56 KB
figure-27.png89.89 KB
figure-28.png109.22 KB
figure-29.png211.88 KB

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jacek replied on Tue, 2008/07/01 - 7:31am

Don't get me wrong, it's a nice effort...but the amount of XML config required to make the most basic of setup makes my stomach turn. Really, most of this should be one method call to some common ancestor or static class to register and configure your views.

I don't want to even think what sort of havoc you could wreck on your app if you did any major refactoring of your code and your IDE didn't update the Spring XML  files correctly.

It seems like the wrong solution for an issue than in 95% of the cases will not change over time any way and hence does probably not need to be soft-coded in XML, down to every last little detail.

But Spring is the hot kid on the block these days, so I guess that's the way everyone is going...I for once would prefer that someone creates something equivalent but lets you configure it with simple annotations like EJB 3.0. Isn't annotation support part of the new Spring release?

 Could this example be re-worked to avoid configuring every single detail in XML and using the new Spring annotations instead?

 

Geertjan Wielenga replied on Tue, 2008/07/01 - 7:46am

Hi Jacek. You get to the heart of a central concern with your comment. Several responses possible: Firstly, I imagine that either the sample could be rewritten to use annotations or, if it can't, that a next release of Spring RCP should make that possible. Secondly, you can try the Swing Application Framework (JSR-296) if you want annotations rather than XML. That framework provides for applications of similar size to those provided by the Spring RCP, without requiring XML. (And the risks of relying on JSR-296 seem to be about the same as relying on Spring RCP, at this point). Thirdly, personally, I don't see the problem with configuring stuff in XML files. In that sense, it is simply a question of taste.

Jacek replied on Tue, 2008/07/01 - 7:52am

Yes, but let's face it....since the project lead left to join Adobe, JSR-296 seems to be as dead as the dodo, if I recall correctly.

https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1567

The last release is from Nov 2007 when Hans was still employed with Sun...doesn't exactly install confidence in the long term viability of this JSR. Say what you want about Spring, but at least it has a large active community.

Geertjan Wielenga replied on Tue, 2008/07/01 - 7:58am in response to: Jacek

Jacek wrote:

Yes, but let's face it....since the project lead left to join Adobe, JSR-296 seems to be as dead as the dodo, if I recall correctly.

https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1567

The last release is from Nov 2007 when Hans was still employed with Sun...doesn't exactly install confidence in the long term viability of this JSR. Say what you want about Spring, but at least it has a large active community.

 

True enough, except that Spring RCP hasn't existed in any real form over the past years. Now it's back but there's no guarantee that it'll go anywhere. (The 1.0.0 release just came out, after two years, and so who knows when the next release will be with us?) I would personally like it to do so (hence this article and hence the tooling I'm providing, should you need evidence), but there's no guarantees (hard to argue with Kirill's comments here). In that sense, depending on Spring RCP is as problematic as depending on JSR-296, but for different reasons. (And that's why I focused only on the technology in this article without being distracted by the politics around it.)

Jacek replied on Tue, 2008/07/01 - 8:03am in response to: geertjan

Kirill always says it like it is. :-)

doclolieven replied on Tue, 2008/07/01 - 11:15am in response to: Jacek

Jacek wrote:

Don't get me wrong, it's a nice effort...but the amount of XML config required to make the most basic of setup makes my stomach turn. Really, most of this should be one method call to some common ancestor or static class to register and configure your views.

You're right, but the registration you speak of is just the sort of locator pattern we want to refactor out of the system. I'm looking into the annotation based configuration, which works great as long as you don't do a lot of configuration besides injecting other beans (f.e. using a propertyplaceholder configurer in conjunction with the component scanning provided in Spring 2.5 is proving to be a real PITA).

I don't think the XML configuration is that much of a burden, if you have a good IDE with Spring support I don't think you'll have a lot of issues. I've worked in a company where all products were made with Spring RCP, and I haven't encountered any problems concerning writing all those bean definitions. There could be some improvement, but I'm thinking more in the line of custom namespaces.

Anyway, you're right in many ways. Things should be simplified. But then again, writing all my forms in YAML also seems a real hassle, and I'm sure a refactor will certainly cause all sorts havoc there too... :)

Jacek replied on Tue, 2008/07/01 - 11:23am in response to: doclolieven

Point taken :-) I guess I just like YAML a lot more than XML (and I think writing the forms in YAML is a lot less hassle than coding them by hand, but hey...I recognize it's an off the beaten path approach).

It just seems that with Spring it's an all or nothing proposition, even the most basic config stuff is externalized. Seems overkill for 90% of apps.

 

Peter Karich replied on Tue, 2008/07/01 - 5:24pm

Great Geertjan!

Thanks a lot!

Does NetBeans handle the refactoring in XML? If yes, how?

>> Secondly, you can try the Swing Application Framework (JSR-296) if you want annotations rather than XML.

Isn't it possible to configure Spring with Java or a scripting language? In picocontainer this is possible with nanocontainer.

Any hints?

Geertjan Wielenga replied on Tue, 2008/07/01 - 5:29pm

No refactoring support of XML is currently handled yet, sorry. Your other question is also good, but I currently don't know the answer. Thanks to you for your earlier article on Spring RCP which inspired this one.

Peter Karich replied on Wed, 2008/07/02 - 3:22am

But wouldn't it be cool to provide those things?

Then NetBeans will be the SpringRC-IDE ;-)

Hint: To create the simple app with your plugin it is required to have the jdk1.6 as default (javax.swing.GroupLayout)

Rohan Ranade replied on Thu, 2008/07/03 - 8:29am

For better NetBeans editor screen shots in Ubuntu - http://blogs.sun.com/gridbag/entry/a_better_look

weggyboy replied on Fri, 2008/09/19 - 5:15am

Hello!

Excuse me, if this is the wrong place for such questions.

I was interested in using a view to display the changes made in another view, both dockable.

How would you do that, when the both views are not known and they are created by the VLDockingApplicationPageFactory?

I though I could implement the Observer Pattern, but since the views are created by the factory I can´t get any Observable object registered in the Observer View.

Any Ideas?

Thanks!

Peter Karich replied on Fri, 2008/09/19 - 12:21pm in response to: weggyboy

Why not adding a listener to the model instead to the view?

Maybe more details are necessary to help you.

weggyboy replied on Sat, 2008/09/20 - 4:03am in response to: peathal

Thanks for your answer Peter!

What I´ve done is exactly that, just I´m having some problems with the GUI actualization, since the form inputs works on a DialogWizard. The Other docked View must first be "resized" before the changes can be shown... Tipical GUI Problem...

 Best Regards!

Wagner

prabithchandranr replied on Tue, 2008/10/07 - 9:47am

How to create wizards in springRCP

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.