Injecting a Splash Screen via Spring into Griffon

Assuming the Spring RCP JARs are in the Griffon application's 'lib' folder, I believe it should be possible to put this into 'Startup.groovy':
import org.springframework.richclient.application.ApplicationLauncher

def startupContextPath = "richclient-startup-context.xml"

try {
    new ApplicationLauncher(startupContextPath)
} catch (RuntimeException e) {
    println 'Failure'

The XML file referred to above has this content:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""

    <bean id="splashScreen" class="org.springframework.richclient.application.SplashScreen">
        <property name="imageResourcePath" value="splash-screen.jpg" />


Together with the referenced 'splash-screen.jpg', the above XML file is in the Griffon application's 'griffon-app/resources' folder, which means that when I invoke 'griffon run-app', both these files are included in the JAR. Here's the application structure:

However, sometimes this seems to work and sometimes it doesn't. Sometimes the splash screen is shown and sometimes not. When it is shown, it is always shown very quickly. But often it is not shown. It is these varying results that are the strangest part of it. Possible reason for the problems—I'm using the wrong lifecycle file (though I've tried all of them). Maybe I should be using the controller somehow, but that seems too late, since the splash screen needs to load before the main window of the application. Maybe this in the controller:

def startupContextPath = "richclient-startup-context.xml";

def loadSplash(){
    doLater {
        try {
            new ApplicationLauncher(startupContextPath);
        } catch (RuntimeException e) {
            println 'Failure'

And then this in 'Startup.groovy':

def rootController = app.controllers.root

Or maybe I should be loading the application context in a different way. However, since the splash screen is shown sometimes, it possibly means that there's something I'm not doing right in the lifecycle files, maybe need to put something in a special thread? But that's all I can think of.

Once the above works, it'll mean that a Spring bean created via Spring RCP has been successfully injected into a Griffon application. After that it should be investigated if/how the docking frameworks supported by Spring RCP can be used within a Griffon application, which would be very cool. One of the benefits from the perspective of Spring RCP users would be that they'd be able to code their Spring RCP application in Groovy.


Geertjan, I believe the splash code would be best at Initialize.groovy, as it is called before any view, controller, model has been created (but after app/builder config has been read).

An alternative would be to use jdk6's splash facilities, but that most likely will require a patch to the run-app command to wire things up.

Keep those Griffon posts a-coming!

Posted by Andres Almiray on September 26, 2008 at 04:45 AM PDT #

Yes, I tried that too. But I'll try again. What's the difference between putting the code straight in the 'Initialize.groovy' and calling from that file to the controller? And, yes, of course, I could use the JDK's splash facilities, but the point of this exercise was to begin integrating Spring RCP into Griffon -- and the splashScreen bean is just an example to get started with. Once this works -- the sky's the limit.

Posted by Geertjan on September 26, 2008 at 04:54 AM PDT #

If the code inside Initialize.groovy tries to call an action on an controller it will fail, as the controller has not been instantiated yet.

I believe Initialize is run inside the EDT so you might want to wrap the code with SwingBuilder.doLater {} or SwingUtilities.invokeLater{} (whichever you prefer ;-)), perhaps that may be the cause of the splash being shown intermittently.

Posted by Andres Almiray on September 26, 2008 at 05:29 AM PDT #

This project needs to move out from spring and replace it with another middleware because if not nobody will touch it.

Posted by Milo on September 26, 2008 at 08:45 PM PDT #

I disagree completely Milo. Spring RCP offers an unbelievable amount of functionality that could be useful to Griffon. Secondly, you're wrong or you misunderstand something, because Griffon doesn't "need to move out from Spring". There's no connection at all between Griffon and Spring -- except that I'm arguing that there COULD be, if you wanted to make use of Spring.

Posted by Geertjan on September 26, 2008 at 10:53 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« July 2016