Graeme Rocher's complete blog can be found at: http://graemerocher.blogspot.com

Items:   1 to 5 of 70   Next »

Moved
Thursday, January 5, 2012

This blog has moved home to Tumblr.

Grails 2.0 Released!
Thursday, December 15, 2011

Long time no post, but after lots of hard work from the Grails core team we are pleased to announce the Grails 2.0 release.

I have posted a comprehensive announcement on the SpringSource blog.

Enjoy!

Grails on Cloud Foundry
Wednesday, April 13, 2011

For those of you who missed it, yesterday we launched the new Cloud
Foundry which we hope will become the premier deployment model for
Grails (and Spring, Ruby, Node.js etc.) applications in the the
future. If you missed the presentation checkout the YouTube recording.

It represents the culmination of a huge amount of work within VMware and we're super excited about the potential it has to completely revolutionize deployment models for Grails applications in the future.

Here are some further resources specific to Grails users:

Website: http://www.cloudfoundry.com/
Wiki & Sample applications: https://github.com/SpringSource/cloudfoundry-samples/wiki/Grails
Tutorial: http://blog.springsource.com/2011/04/12/one-step-deployment-with-grails-and-cloud-foundry/
Plugin Documentation: http://grails-plugins.github.com/grails-cloud-foundry/docs/manual/index.html

Signups are currently on a first come first serve basis under a limited beta programme.

Reading i18n messages from the database with Grails
Friday, April 16, 2010

In a recent consulting engagement, a client wanted to know how to go about reading i18n messages from the database rather than static properties files (the default in Grails). Considering how easy this is to do I was surprised when I Googled it that there was no information on how this is achieved.

Anyway it's dead simple. Just create a domain class that models a message:

class Message {

String code

Locale locale

String text

}


Then implement a class that extends the org.springframework.context.support.AbstractMessageSource class. In the example below I am using simple GORM finders to lookup a message using the code and locale

class DatabaseMessageSource extends AbstractMessageSource {


protected MessageFormat resolveCode(String code, Locale locale) {

Message msg = Message.findByCodeAndLocale(code, locale)

def format

if(msg) {

format = new MessageFormat(msg.text, msg.locale)

}

else {

format = new MessageFormat(code, locale )

}

return format;

}

}


Then wire it in using Spring by configuring a "messageSource" bean in the grails-app/conf/spring/resources.groovy file:

beans = {

messageSource(DatabaseMessageSource)

}


And that's it. Now you're serving messages from the database. Of course this is a terrible inefficient implementation since we're hitting the database for ever message code used in the application. However, it's pretty easy to introduce caching. Just create a cache key:

@Immutable

class MessageKey implements Serializable {

String code

Locale locale

}


Then configure an appropriate cache bean (I'm using Ehcache) in Spring and wire it into your MessageSource:

beans = {

messageCache(EhCacheFactoryBean) {

timeToLive = 500

// other cache properties

}

messageSource(DatabaseMessageSource) {

messageCache = messageCache

}

}


Finally, update your implementation to use caching:

class DatabaseMessageSource extends AbstractMessageSource {


Ehcache messageCache

@Override

protected MessageFormat resolveCode(String code, Locale locale) {

def key = new MessageKey(code,locale)

def format = messageCache.get(key)?.value

if(!format) {

Message msg = Message.findByCodeAndLocale(code, locale)

if(msg) {

format = new MessageFormat(msg.text, msg.locale)

}

else {

format = new MessageFormat(code, locale)

}

messageCache.put new Element(key, format)

return format

}

return format;

}

}





Grails - dependency resolution done right
Thursday, September 17, 2009

Over the past couple of weeks I have been working on improving Grails dependency resolution capabilities for both applications and plugins. In previous versions of Grails (1.1 and below) you had limited options when it came to dependency resolution.

You could use the Grails Maven plugin, but that forced you to use, heavin forbid, Maven. We also shipped with basic Ant + Ivy support, but it was only really designed to be used for automation with continuous integration servers that support Ant and not at development time.

With Grails 1.2 this all changes with the introduction of Grails' dependency resolution DSL, which you can use to define your dependencies. Built on Ivy we have now eliminated one of the last remnants of XML usage in the Grails framework:
    dependencies {
      runtime 'com.mysql:mysql-connector-java:5.1.5'
      test 'junit:junit:3.8.2'
  }
Grails takes application defined dependencies (defined in grails-app/conf/BuildConfig.groovy) and merges them with dependencies defined in the framework or any installed plugins. If there are conflicts you can exclude dependencies inherited from the framework or you can override plugin dependencies.

By default Grails will only resolve dependencies against your Grails installation but you can enable remote repository resolution easily:
repositories {
      mavenCentral()
mavenRepo "http://repository.codehaus.org"
}
If you're addicted to your pom.xml file then we have even added the ability to read dependencies from the pom.xml instead of using the DSL. All in all, Grails 1.2 will give you significantly better control over dependencies and how they are resolved.

We're still on track to release Grails 1.2 by the end of the month, but if you want to hear more about it I'll be talking about Grails 1.2 at upcoming events such as JAOO (Denmark), SpringOne2GX (New Orleans, USA) and the Grails eXchange (London). See you there!

Items:   1 to 5 of 70   Next »





© 2013 SpringSource, by Pivotal Labs & No Fluff, Just Stuff TM. All rights reserved. Java is a registered trademark of Oracle.