The MetaSieve Blog

August 25, 2010

Using Cometd 2.x with Grails

Filed under: Uncategorized — Tags: , , , — Björn Wilmsmann @ 8:16 pm

I’ve been struggling quite a bit to get CometD (see this for more information on the Comet Pattern) working with Grails and the corresponding Grails CometD plugin, the documentation being sparse and the new version of the CometD API being somewhat confusing with lots of new interfaces and abstractions.

Anyway, I’ve got it working so I thought, I might share the experience (see code sections at the end of the article for copying source code):

Assuming that you would like a Grails service to communicate via CometD, this is how a basic implementation of a simple service that finds Account entities for search parameters would look like:



There are a few things to note here. The service implements the interface InitializingBean provided by Spring. This interface supplies an afterPropertiesSet() method that allows you to initialize additional properties after Spring has wrought its magic. This way you can initialize and handshake with the Bayeux server using the bayeux bean that’s injected by the CometD plugin.

The runAsync closure in findAccounts(def query, def params = [:]) is provided by the Grails Executor plugin, which allows you to run background threads in your application without losing the Hibernate session. This is exactly why runAsync is needed here. As findAccounts(def query, def params = [:]) will be called asynchronously we have to make sure everything that occurs inside this method is thread-safe.

Via the subscribe() method you can have a so-called SubscriberListener subscribe to a messaging channel:



Such a SubscriberListener has to extend the abstract class SessionChannel.SubscriberListener as provided by org.cometd.bayeux.client.SessionChannel. This class demands that its sub-classes provide an onMessage(SessionChannel channel, Message message) method, which will act as a callback method upon new messages on the channels the listener is subscribed to.

Apart from that, there’s some nice Groovy magic happening here that allows you to instantiate a MySubscriberListener which calls a service method without actually hard-coding that service method in the MySubscriberListener class. In this case, the listener will call the service’s findAccounts(def query, def params = [:]) method.

The client side of this little example would look something like this (assuming you’re using the jQuery version of the CometD client), with cometd-subscriptions.js being loaded first and init.js afterwards:





Once this is all set up, you can do something like this to nudge AccountService from your JavaScript client:

$.cometd.publish('/requests/search', { 'payload': { q: 'some query', params: { offset: 10 } } });

I hope this primer helps you to overcome initial problems with CometD and Grails. If you’ve got any questions or additional contributions, please feel free to leave a comment.

Source code for copy & paste:


package myapp

import grails.converters.JSON

import org.springframework.beans.factory.InitializingBean

class AccountService implements InitializingBean {

def bayeux
def bayeuxSession

static transactional = true

void afterPropertiesSet() {
bayeuxSession = bayeux.newLocalSession()
bayeuxSession.getChannel('/requests/search').subscribe(new MySubscriberListener
(this, 'findAccountsToFollow', ['q', 'params']))

def findAccounts(def query, def params = [:]) {
runAsync {
def accounts = Account.findAllByName(query, params)

// publish to search results channel
bayeuxSession.getChannel('/results/search').publish(['payload':['accounts':accounts]] as JSON)


package myapp

import org.cometd.bayeux.Message
import org.cometd.bayeux.client.SessionChannel

class MySubscriberListener extends SessionChannel.SubscriberListener {
def callbackService
def callbackMethod
def callbackParams

public MySubscriberListener(def service, def methodName, def params = []) {
callbackService = service
callbackMethod = methodName
callbackParams = params

public void onMessage(SessionChannel channel, Message message) {
// callback
def callbackParamValues = []
callbackParams.each { param ->



var subscriptions = {};

function refreshCometSubscriptions(channels, callbackFunctions) {
for (var i in channels) {
if (typeof channels[i] == 'string') {
subscribeToCometChannel(channels[i], callbackFunctions[channels[i]]);

function unsubscribeFromCometChannel(channel) {
if (subscriptions[channel]) {
subscriptions[channel] = null;

function subscribeToCometChannel(channel, callbackFunction) {
subscriptions[channel] = $.cometd.subscribe(channel, callbackFunction);


// initialize cometd
var channels = ['/test', '/results', '/results/search'];

var testCallback = function() { };
var resultsCallback = function() { };
var searchResultsCallback = function(message) {
renderFollowerSearchResults(JSON.parse(, '#resultsContainer', 'resultList', '#box2');

var callbackFunctions = { '/test' : testCallback, '/results' : resultsCallback, '/results/search' : searchResultsCallback };

$.cometd.addListener('/meta/connect', function(message) {
if ($.cometd.isDisconnected()){
if (message.successful) {
$.cometd.publish('/test', { 'data': { 'message':'Connection with CometD server has been established.' } });
refreshCometSubscriptions(channels, callbackFunctions);


August 20, 2010

i18n in web apps with Dashcode

Filed under: Uncategorized — Tags: , , — Björn Wilmsmann @ 1:54 pm

For quite some time I’ve been searching for a way to properly localize strings in a web app created with Apple‘s otherwise fantastic Dashcode application.

When creating a Dashboard widget there is a special panel for adding languages and translations to your project. However, for some reason that panel is missing from web application projects in Dashcode, so there seems to be no straightforward way to provide a web app created with Dashcode in multiple languages.

Apple’s documentation on the subject – being sparse as usual – wasn’t any help either.

So finally, be reverse engineering the way localization is done in Dashboard widgets I was able to come with my own solution. Here goes:

  1. Add a file named utilities.js with the following content to the project root:

    function getUrlParameters()
    var vars = [], hash;
    var hashes = window.location.href.slice(window.location.href.indexOf('?') + 1).split('&');
    for(var i = 0; i < hashes.length; i++)
    hash = hashes[i].split('=');
    vars[hash[0]] = hash[1];
    return vars;
  2. Add a file named i18n.js with the following content to the project root:

    var lang = getUrlParameters()['lang'];
    if (!lang || lang === '') {
    lang = 'en_GB';
  3. Add a file named localizedStrings.js with the following content to the project root (The hash entries and languages are of course mere examples.):

    var localizedStrings = {}

    if (lang === 'de_DE') {
    localizedStrings = {
    "Konto": "Konto",

    if (lang === 'en_GB') {
    localizedStrings = {
    "Konto": "Account",

  4. Add the following lines (in exactly the same order) to your index.html right above the entry for main.js:

    <script type="text/javascript" src="../utilities.js" charset="utf-8"></script>
    <script type="text/javascript" src="../i18n.js" charset="utf-8"></script>
    <script type="text/javascript" src="../localizedStrings.js" charset="utf-8"></script>

Voilà, you’re ready to go. In the example above any text, e.g. button labels, in your app that equals “Konto” will automatically be translated to “Account” if lang is set to “en_GB”.

July 15, 2010

A UI concept for iOS 4 multitasking on the iPad

Filed under: Uncategorized — Björn Wilmsmann @ 10:38 pm

I just had this idea for a multitasking UI with iOS4 on the iPad:

You get the idea?

Apple engineers, please feel free to copy …

May 15, 2010

Natural Language Processing in Groovy: A Primer – Using Groovy for processing and analysing textual data

Filed under: Uncategorized — Tags: , , — Björn Wilmsmann @ 1:00 am

The May issue of GroovyMag, an online-only magazine for everything Groovy and Grails has been published today.

I’ve contributed an article about doing natural language processing with Groovy. Here’s a teaser:

Given that most Internet content in way or another contains natural language, then it’s no surprise natural language processing (NLP) and text mining have become a vital aspect of many Internet applications – from large scale search engines to social media apps. Making sense of the content that is stored in your application can make all the difference. Groovy’s regular expression, text processing abilities and readily available NLP libraries for Java make it a natural match for processing large amounts of text.

Since its inception Perl, the language that arguably can be considered the first scripting language in modern terms, had the features necessary to conveniently process large amounts of text built right into the language. Fortunately, most scripting languages that followed Perl borrowed and inherited many of these useful features. This is why things like methods for reading texts and regular expressions are commonplace in Python, Ruby and, of course, Groovy too.

[ … ]

Read the rest of this article at GroovyMag.

Related links:

April 15, 2010

Using Groovy for Measuring Statistical Dependence – How to make predictions about the relatedness of statistical events

Filed under: Uncategorized — Tags: , — Björn Wilmsmann @ 10:04 pm

The April issue of GroovyMag, an online-only magazine for everything Groovy and Grails has been published today.

I’ve contributed an article about measuring statistical dependence with Groovy. Here’s a teaser:

Statistical dependence is all about finding out which events in a statistical sample are likely to co-occur, that is if one event occurs it can be predicted with a certain probability that another event will occur as well. Using simple measures of statistical dependence I’d like to show how Groovy can be used to make such predictions.

Processing and reporting statistical data is commonplace in software development businesses today. It’s used for all sorts of things including business performance indicators, website or user tracking statistics, searching and indexing textual content on a website or any other content repository.

Each of these applications,and many more for that matter, to some extent require that statistical data be collected and possible relations between single events be identified.
Common examples of statistical events are purchases made by a customer, actions taken by a website user or word occurrences in textual content.

From this kind of events potentially useful information can be derived:

  • products which are likely to be purchased together and thus can be provisioned and stocked accordingly
  • the click stream users will probably take on a website
  • related words can be suggested to the user in an auto-complete feature

I’ll cover the basic steps for making such predictions with Groovy. First things first, we’ll start by gathering the necessary data.

[ … ]

Read the rest of this article at GroovyMag.

Related links:

April 2, 2010

Kameleoon: Morphing The Web (with Grails)

Filed under: Uncategorized — Tags: , , , , — Björn Wilmsmann @ 6:00 pm

The way we do web design more or less hasn’t changed for more than 10 years or so. Most new websites start from scratch design-wise, meaning that when you have a cool idea for a new website you hire a web designer for turning that idea into something that’s nice to look at.

Another option is using some blogging software or CMS like WordPress or Joomla alongside with predefined templates that are shipped with the software. While the latter option surely is satisfactory for many purposes (see this blog, for instance …), it doesn’t allow you a great deal of customization.

One final option is using one of those clunky homepage toolboxes which allow you to ‘design’ your own website with virtually no knowledge of HTML, CSS or graphic design. However, these most of the time impose rather narrow restrictions as to what can be done with them and what cannot. This goes as far as that most of the time you can tell right away which of those toolboxes has been used.

Enter Kameleoon. Kameleoon is a pretty new service that approaches web design rather differently.

It allows you to take any existing website (So, admittedly you’d have to do some initial web design before using Kameleoon, too.) and modify each and every CSS property in a nifty WYSIWYG editor. You can change colours, border styles, font types, upload background images and the changes will be applied right in place. You don’t even have to touch your server-side code anymore when applying design changes! Pretty cool, isn’t?

Technically, this is done by adding a JavaScript snippet to your website that loads the Kameleoon scripts, CSS files and renders any changes you’ve made so far. Kameleoon doesn’t care about the technology used on your website (well, apart from Flash, that is …). You can gain some more control about what can be changed by Kameleoon adding additional CSS classes to your HTML code though.

Kameleoon‘s user interface might admittedly be a bit overwhelming at first and needs some time to get used to. But, then again, so does Photoshop, doesn’t it?

The Kameleoon application runs on Grails 1.2.1. The rendering engine makes use of GIMP scripted via Python. One very cool thing about this is that the Python code is dynamically generated by Groovy.

Finally, the client side JavaScript code was written with Qooxdoo, a framework for creating rich Internet applications.

March 17, 2010

Continuous Testing with Grails

Filed under: Uncategorized — Tags: , , — Björn Wilmsmann @ 12:37 am

I’ve just released a new Grails plugin called AutoTest. AutoTest provides an automatic (or continuous) testing feature for Grails. After having installed AutoTest you will be able to run the following new Grails script:

grails auto-test

This will start a continuously running Grails test process. Once you modify and save a file within your Grails project unit and integration tests (and as a matter of fact any kind of tests added by plugins) will be run against the new version of the changed file.

This allows you to get continuous feedback on code changes without having to switch between editor and terminal.

For more information, please have a look at the plugin documentation

March 5, 2010

Does Grails have a problem?

Filed under: Uncategorized — Tags: , , , — Björn Wilmsmann @ 5:29 pm

Recently (or rather over the course of the last half year or so), there has been quite some discussion about how the Grails community responds to open source contributions, mainly with regard to Grails plugins.

The main issue Robert Fischer takes offence at is that the Grails community seems less appreciative of contributions, especially with regards to plugin development, than other open source communities like Rails.

According to Robert, Grails users are more demanding in terms of support for open source components. There seems to be a notion of ‘You built it so support it!’ within the Grails community whereas other communities nourish a more cooperative DIY style.

Now, when developing software for commercial purposes ‘You built it so support it!’ is perfectly fine but given that most open source developers don’t get compensated directly for their efforts this is problematic at least. Sure, open source work can gain you a decent job, marketing buzz or new customers for your company but this alone in most cases doesn’t justify doing extensive and often painful support.

I think the root of the matter is the cultural background of Grails in contrast to the background of projects like Rails:

While Rails has been born out of explicit disdain for ‘enterprise’ culture with all its complexities and often cumbersome nonsense, Grails tried to build upon a few positive aspects of enterprise software culture like reliability, scalability and security and do away with unproductive, complex boilerplate code at the same time.

So, while those two frameworks aren’t that different in terms of features and what can be achieved with them, each comes from and mainly caters for a distinctly different background.

Regarding the matter at hand, the problem with the enterprise background of Grails chiefly is that enterprise customers expect to pay often bizarre amounts of money for software allowing them to hold the creators of said software responsible and demand extensive support from them.

In a way this notion maybe shines through here as well. In the enterprise segment people are used to getting support for the software they use so they also demand this kind of support from open source developers, who mostly happen to create their stuff in their spare time.

While I’m perfectly fine with releasing my own plugins under the Apache license and support them whenever I have time to, I can completely comprehend Robert’s point of view and his desire to get a different kind of compensation for his open source work. In fact, there should be plenty of space for both approaches (and anything that lies in-between) within open source software development.

However, in my opinion the Grails community – especially those relying on Grails for commercial applications – does indeed have a problem if one of its most prolific plugin authors feels like he has to resort to such rather unusual measures to gain appreciation for the work he’s doing.

Moreover, although I consider a commercial market for Grails Plugins an interesting idea, I don’t think this is a viable alternative for plugin developers and users alike.
This would first of all require a much wider adoption of Grails to allow developers to get a decent amount of money from plugin development.
Secondly, this would most likely exclude smaller enterprises from adopting Grails at all.

Your thoughts?

List of related articles:

March 1, 2010

MagicNumbers: Dynamic Time and Byte Calculations for Grails – Using the Meta Object Protocol to add behaviour to Grails at runtime

Filed under: Uncategorized — Tags: , , — Björn Wilmsmann @ 1:00 pm

The March issue of GroovyMag, an online-only magazine for everything Groovy and Grails has been published today.

I’ve contributed an article about the Grails MagicNumbers plugin you might find interesting. Here’s a teaser:

Grails plugin development and Groovy‘s Meta Object Protocol are powerful tools for adding runtime modifications to standard Java classes. Introducing the new Grails MagicNumbers plugin, I’d like to show how metaprogramming in Groovy can be used to make code both more readable and easier to write. The MagicNumbers plugin allows you to write readable code like 3.days or 6.megabytes instead of having to manually calculate the equivalent number of seconds or bytes.

[ … ]

Code like this obviously has several advantages over manually calculating and writing the actual numbers:

  • It is written much more easily.
  • The code is much more readable. You can even show this code to someone who hasn’t any programming experience at all and she will immediately understand its purpose.
  • The code is less error-prone and thus more maintainable.

So, I wanted to have this kind of magic in Grails as well. Fortunately, due to Groovy’s Meta Object Protocol and the Grails plugin framework, this kind of functionality can be added quickly and elegantly.

[ … ]

Read the rest of this article at GroovyMag.

Related links:

January 8, 2010

Using Grails for creating UML diagrams

Filed under: Uncategorized — Tags: , — Björn Wilmsmann @ 7:59 pm

Back in the old days (like, 5 years ago …) when embarking upon a new software project you would (hopefully, that is …) usually start by sketching the underlying model using ER or UML diagrams.

No matter if you’re on the more enterprisey side of software development that requires more complex upfront documentation or if you’re going down the agile road, there had to be at least some sort of a model.

Problem is, once you’ve drawn that model in your favourite UML design tool or just with good ol’ pen & paper, you have to turn that model into code. Although the more expensive UML design tools allow for code creation and sometimes even feature round-trip abilities (that is code changes are reflected in the diagram), most of them are far from perfect in that they mostly produce fairly generic Java code that has to be heavily customised depending on the framework you’re using.

Even worse, if you use another language like Groovy or Ruby you likely have to start writing code from scratch.

However, fortunately for Grails there are two nifty plugins that offer an elegant way out (see for a Rails solution):

Both automatically create UML diagrams for your app’s domain model. The main difference between those two is that the former draws upon, a very promising web service that allows you to create UML diagrams with a Wiki-like syntax.

So, nowadays I don’t even bother firing up Visual Paradigm – the UML design tool I liked best before – anymore when I have to design a domain model. All I do is run ‘grails create-app’ and start writing actual domain class code! Thanks to GORM, Grails‘ object-relational mapping, writing actual code is easier and faster than drawing diagrams in a design tool.

Once I’m done I can use one of the plugins mentioned above to create a shiny UML diagram for impressing the customer and documenting the current state of the application.

Update: Sven Lange wrote a nice and more detailed blog post about Grails and UML diagrams, too:

Older Posts »

Blog at