Original Source

Glen Smith delivers the second half of his ‘concoction’ of JMS/Grails/OpenMQ. If you remember the first time he described how the Grails JMS Plugin can be used to post messages to a queue from a service. The other half of the solution involves Message Driven POGOs (no, not the jumping sticks, but Groovy beans).

When we last left this story, I was talking about integrating Grails and JMS so that groovyblogs can put all of its feed and thumbnail fetch requests on a JMS queue. Now it’s time to look at the second half of the story. How my standalone groovy feed/thumbnail fetcher can pick requests off the queue, and put a response back on a different queue.

First a little background. Spring makes writing message driven POJOs really tidy. Groovy makes it even tidier. To implement a POGO (Plain Old Groovy Object) that listens on given Queue, I just have to implement the MessageListener interface, and provide an onMessage routine. Spring will setup the necessary background thread poller that will invoke my bean when a new message arrives on the queue. It will also look after the connection pooling to my JMS server so I’m not creating/dissolving connections every time. Nice.

But if I want to put something on the queue? Then it’s time to use Spring’s JmsTemplate class which provides the necessary convertAndSend that I’ll need to put my Map object back on the queue with my thumbnail result.

Due to the fact that Grails sits atop the Spring framework, Message Driven POGOs are trivial to implement, almost criminal as some say. As Glen describes the steps are simple:

• have your MD POGO implemente javax.jms.MessageListener
• add a jmsTemplate property, it will be injected by Spring
• call jsmTemplate.convertAndSave() when you want to post something to the queue
• don’t forget to setup the required bean mappings on your application context

Of this steps perhaps the most verbose is the setup of the application context (Glen went with the XML version) but perhaps Grails’ Spring BeanBuilder can help in reducing the angle bracket noise, don’t you think?

Tags: Glen Smith, Grails

Original Source

Glen Smith writes about his experience with Grails, JMS and OpenMQ. As you probably know, Glen is responsible for groovyblogs.org , which has been recently upgraded to a messaging architecture.

I’ve just finished converting groovyblogs over to a (largely) message driven architecture. I’m a bit of an JMS noob, but the adventure has been fantastic, and it’s time to write some stuff down. The reason I’m even interested in a messaging is for the acquisition of feed xml and thumbnails. I presently do the former in-process in the app server, and the later via Groovy XML-RPC to a Thumbnail Server running locally.

My re-design involves creating four queues: urlRequest, urlResponse, thumbnailRequest, thumbnailResponse. The webapp will put the requests on the request queues, then an external process will deliver source the the thumbnails and feed data (external to the app server) and deliver them on the response queues. All the db action remains in the webapp, so all my hibernate/GORM goodness can continue as usual.

First off was choosing an MQ provider. ActiveMQ seems to have all the mindshare, and was easy to install, but I had quite a bit of trouble actually getting it working correctly. My clients would frequently drop their connections, messages were undelivered since I terminate JmsTemplate connections incorrectly, messages were not delivered on reconnect, and it was generally unforgiving to my JMS noob-ness. I’m sure it’s not ActiveMQ’s fault. But it wasn’t a great experience for me. YMMV.

Then I found out that OpenMQ ships embedded right into Glassfish, so I made the switch and have been happy every since. When I’m running outside of the container ("grails run-app"), I just run a standalone copy of OpenMQ to test against, and when I deploy to Glassfish, I just use the embedded one. Sensational! OpenMQ ships with a funky Swing admin tool, but the only thing it didn’t have was a funky Queue content browser (like the Web one that ships with ActiveMQ, but I setup Hermes-JMS and now I can happily browse the contents of both local and remote queue.).

After settling on OpenMQ as his MQ provider of choice, Glen then turned to the Grails side of the equation. Thanks to the thriving Grails plugin community he didn’t waste too much time integrating JMS into groovyblogs. Enter the JMS Plugin for Grails . It makes the job fairly easy, after all it follows the Grails ways, so you can be sure you will find a fair share of convention over configuration, mapped closures, metadata-as-properties and extended artifacts to get yourself on the right track.

Ok. I had my JMS platform, now it was just a matter of getting the data into and out of those queues. Enter the JMS Plugin . This plugin rocks so hard! Define a service that has an expose = ['jms'] and life will be good for you. To listen on the queue, just define an onMessage closure. You can use naming conventions to map to existing queue names, but in my case I had specific ideas on what I wanted the queue to be called, so I set an explicit ‘destination’

All the messages I pass around are normal java.util.Map objects, which makes it easy to ship a bunch of payload at once. Once that’s done, anything that ends up on the thumbnailResponse queue will get automatically passed to my onMessage routine.

This article describes how to setup the environment to get messages on the queue, Glen promised to write a follow-up describing how to get messages off the queue by some processing POGOs.

Tags: Glen Smith, Grails

Original Source

Glen has been busy updating groovyblogs.org to the latest Grails 1.0.3 release. He also took this opportunity to update some features and rework the site to accommodate messaging (JMS). Now he writes about his experience setting up JNDI datasources.

Today I’ve moved a bunch of my Grails apps over to JNDI Data Sources, and while it’s fresh in my mind, I thought I’d document a few of the tips and tricks involved.

First of all, why would you even want to use JNDI data sources? A few good reasons:

• Most importantly, your app server can probably manage your database connections a lot better than you can
• You don’t have to embed your username/password data in config files, and then end up committing them to public repos (this has led to several password changes for me in the past… the shame!)
• Developers can call their local databases whatever they want (and they can be whatever type of database server they like) - just map the JNDI reference to whichever server and database floats your boat.
• Does away with the need to ship db-specific drivers with your app (well.. in theory.. if you’re using Jetty for your DEV work , this may well not be true)

Glen shows portions of his configuration files, while at the same time giving a valuable warning: setting JNDI datasources with embedded Jetty on the development environment requires different settings compared to the production environment. He then proceeds to explain what to change between production environments.

Tags: Glen Smith, Grails

I’ve been working on my little app to Sync Outlook to Remember The Milk and having a great time learning GroovySWT along the way. GroovySWT offers a SwtBuilder and JFaceBuilder (simple DSL) for putting together SWT/JFace applications. Now I’m a huge fan of both SWT and JFace, so I was very keen to see what GroovySWT could let me do from straight groovy code.

It’s very early days for the GUI, but I’ve thrown together some scratchy ideas using the Tango Icon Library to get a basic interface underway.

I still think the ideal way to build GUIs is with a tool. Even with the sensational DSLs that SwingBuilder and SwtBuilder give you, nothing beats dragging and dropping stuff around (personal fave is SWT Designer, which is unbelievably good - FD: I managed to get a free copy from the early days).

But if your GUI is very simple (like the one shown above), it really does seems a shame not to be able to throw something together really quickly using straight groovy, and GroovySWT gives you that in spades. How about a little Preferences dialog for your app which automatically persists user entries to a .properties file?

preferenceDialog() {

    preferencePage( title:"Proxy Settings", filename:"syncthemilk.properties" ) {
        booleanFieldEditor( propertyName:"proxyEnabled", title:"Enable Proxy" )
        stringFieldEditor( propertyName:"proxyHost", title:"Proxy Host" )
        integerFieldEditor( propertyName:"proxyPort", title:"Proxy Port" )
    } 		

    preferencePage( title:"RTM Settings", filename:"syncthemilk.properties" ) {
        stringFieldEditor( propertyName:"rtmToken", title:"RTM Token" )
    }
}

I’ve found a few little bugs in the current groovy-swt source which I’ll bundle up in a patch and submit once I have the full GUI for my app done. That should let me exercise a good part of the library.

The only major shortcoming I’ve found so far is there is virtually no documentation. There are, however, a ton of good examples that demonstrate many of the cool and interesting parts of the library (including tray integration, properties dialogs, wizards, and more). I’ll update the Groovy wiki with some new info once I’ve had a chance to get my own GUI done.

Huge props to Christiaan ten Klooster for all the fantastic work he has put into GroovySWT. Really a first class effort.

– Glen Smith

Tags: Glen Smith