Geertjan's Blog

  • September 25, 2008

Injecting a Splash Screen via Spring into Griffon

Geertjan Wielenga
Product Manager
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="http://www.springframework.org/schema/beans"
<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.

Join the discussion

Comments ( 5 )
  • Andres Almiray Friday, September 26, 2008

    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!

  • Geertjan Friday, September 26, 2008

    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.

  • Andres Almiray Friday, September 26, 2008

    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.

  • Milo Saturday, September 27, 2008

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

  • Geertjan Saturday, September 27, 2008

    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.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.