Recent Posts by Geertjan Wielenga

To get them to co-exist, somehow Spring RCP's application class should replace the Griffon application class, or the other way round. Maybe I need to create an ApplicationBuilder for Spring RCP? There's also threading issues to figure out. Anyway, right now I'm able to show both applications: the Griffon application and the Spring RCP application (at least, their main windows): Here's the application context, containing one single bean only, for the application class: <?xml...

Here's my Spring application context: <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <bean id="sysProps" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> <property name="targetClass"> ...

The NetBeans window system can be used "as is" in, I guess, 90% of cases. However, it's that final 10% that's always the problem! That's when the NetBeans window system becomes, potentially, a little bit painful. Less so, though, when you become aware of the MANY different ways in which you can tweak it. I want to illustrate this point by means of a concrete example. You're working on a welcome screen with the following requirements: It should be undocked when the application...

In An Approach to Pluggable Griffon Applications, I discussed how the JDK 6 ServiceLoader class is useful in the context of Griffon. In effect, it provides Griffon with plugins. However, the ServiceLoader doesn't have the concept of 'hot deploy'. Changes made on the classpath are only presented to a Griffon application upon restart. Let's take an alternative approach—instead of the ServiceLoader class, we'll use the Lookup class. Just add org-openide-util.jar from the...

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.ApplicationLauncherdef 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...

I got tired of seeing the Grails icon whenever I was working with Griffon, so fashioned my own Griffon icon and then recreated the whole set of modules from scratch, with a completely fresh check out from hg. I.e., the first time I did everything on a hunch: I had the hunch that getting from Grails support to Griffon support would be a matter of branding. This time, I knew that was true, so went about it all a bit more carefully and have come up with a more reliable result....

It's not like I'm constantly looking for useful scenarios for Griffon and then blogging about it. It's more like I keep tripping over them accidentally, all the time. I just can't help it! Here's the latest one. Let's say you watched Roumen's very cool Javalobby NetBeans Visual Library Presentation. "Cool, you think, let's learn about that." At some point you put together a piece of code like this: public class GraphSceneImpl extends GraphScene { private LayerWidget...

The first Griffon issue is solved: I made the mistake of including "pack: true", which fails in applets. Now I can start playing a bit with the applet side of Griffon. So, this is the pluggable Griffon application discussed yesterday: In what way is the application pluggable? Read yesterday's blog entry but, in summary, be aware that none of the items in the list that you see above are defined in the Griffon application. Each item is made available by a different service...

If I were someone evaluating the existing Swing desktop frameworks, I wouldn't hesitate to choose the NetBeans Platform over Griffon or Spring RCP—for one very specific reason: any application built atop the NetBeans Platform is inherently extensible. John O'Conner's definition of extensibility applies here: "An extensible application is one that you can extend easily without modifying its original code base." In this sense, a plugin is not what Grails understands a plugin to...