Grails Exchange

Last month I did a talk on behalf of the Java Web User Group (JavaWUG) at the Grails Exchange. Unfortunately, I did not go to the full conference but it was nice to pop in and attend a couple of the evening sessions, do my bit, and join in for a beer and chat aftewards.

The thrust of my talk was on embedding Grails into Java applications. Grails is a full-stack framework, which aims to solve an overlapping set of problems to Impala. I feel lured towards Groovy, but every time I get put off by my perception that Groovy is too slow. I'm not talking about execution speed, more compile speed.

Anyway, there could be a nice synergy with Impala and Grails - Impala for a standard Spring-based back end, and Grails for the front end. That's certainly a part of the reason for my interest in embedding Grails in a typical Java application.

Impala, of course, works out of the box with Spring MVC, but it would be great to get integration going with other frameworks. One of the key requirements for a web framework integration with Impala is that the web application is itself dynamically reloadable. Of course, you could integrate Impala with any statically reloading web application, but it seems a bit pointless having dynamically reloadable back-end functionality while still having to restart the application every time you want to make a change to one of your presentation classes. Grails seems to fit the dynamic reloadable requirement quite well. However, unpicking it's functionality so that you can reuse it outside of the Grails environment is not trivial.

Here's some code which goes part of the way to achieving this task.

public static void main(String[] args) throws IOException {
    MetaClassRegistry registry = GroovySystem.getMetaClassRegistry();

    if (!(registry.getMetaClassCreationHandler()
        instanceof ExpandoMetaClassCreationHandle))
        registry.setMetaClassCreationHandle(new ExpandoMetaClassCreationHandle());

    FileSystemXmlApplicationContext cpc =
        new FileSystemXmlApplicationContext("web-app/WEB-INF/grails-context.xml");
    DefaultRuntimeSpringConfiguration springConfig =
        new DefaultRuntimeSpringConfiguration(cpc);

    GrailsApplication application = (GrailsApplication) cpc.getBean("grailsApplication");
    application.registerArtefactHandler(new ControllerArtefactHandler());
    application.registerArtefactHandler(new TagLibArtefactHandler());
    application.registerArtefactHandler(new DomainClassArtefactHandler());

    application.getConfig().put("plugin.includes", "filter, controllers, taglib");

    DefaultGrailsPluginManager pluginManager =
        new DefaultGrailsPluginManager(new Class[] {}, application);
   
    WebApplicationContext context = springConfig.getUnrefreshedApplicationContext();
    pluginManager.setParentApplicationContext(context);
    pluginManager.loadPlugins();

    pluginManager.doPostProcessing(context);
    pluginManager.doRuntimeConfiguration(springConfig);
    pluginManager.setApplicationContext(context);
    pluginManager.doDynamicMethods();
   
    WebApplicationContext ctx = springConfig.getApplicationContext();

    System.out.println(Arrays.toString(ctx.getBeanDefinitionNames()));
}

Note that this code will fire up Grails, load its web-specific plugins. The trick now is to get the rest of the environment working, so that a full Grails web application can slot neatly into Impala's environment. Something I'll be trying in the next few weeks.

Impala moved to Google code

I've just moved Impala from Java.net to Google code.

Here's the new link: http://impala.googlecode.com/

Here's why.

I originally set Impala up with Java.net because I wanted project hosting which would be simpler, quicker and easier to maintain than Sourceforge, where I had previously hosted projects. On the whole things did work out that way, but there are a few things about Java.net that I don't like.

First, and this is a biggie, there doesn't appear to be anonymous SVN source access. This means that people who want to check out the source code need to sign up to Java.net, and for some people this is definitely likely to be a barrier to trying out the project, and hence to the project's adoptions.

On a related issue, there doesn't seem to be direct web-based SVN browsing available. I can't send a link which points directly to a source file on the SVN repository.

Second, it seems to have quite a complicated roles and permission system that I didn't immediately understand and still don't. Frankly, the only roles or permissions I'd be interested in are project owner, committers and everyone else. Anyone should be able to see anything; only developers should be able to change things.

Thirdly, while everything seems nicely packaged, the tools seem a bit dated. The bug tracker, which I hadn't started looking, looked like a wrapper around bugzilla.

On the whole, the site has a bit of a clunky feel - I'm not that big a fan of the CollabNet software. I wouldn't expect this to change dramatically too soon, because I can just imagine the pain that would be involved with upgrading.

Finally, setting up the project took a bit long. It took a couple of weeks before it was put in the Enterprise Incubator category. There's just a bit too much process around the project setup. I want plain and simple hosting. The users and community as a whole, and not some Sun employees, will decide if there is any merit in the project.

Google Code, on the other hand, was really no frills in its setup. The tools seem very simple to use. Everything is laid out clearly. I didn't need to spend ages figuring out how the site works. Google generally does a good job at creating usable applications, and this one doesn't seem to be any different.

Of course, there is anonymous SVN access for casual users. I like the tabbed layout of the project home page. The bug tracker looks simple but very functional, and the same goes for the wiki. And, as you'd expect with Google, there is good indexing and search capability, so that documentation and source code is searchable.

All in all, it made sense to change sooner rather than later, as the project is in a very early, pre-adoption phase. The job would be much more painful later on. Now I've got to rename the packages!