Colin Harrington

This past month, I did a presentation at the Groovy Users of Minnesota which I called Grails: The View Layer.  We took our time delving into the Groovy Server Pages, how Grails utilizes Sitemesh and some of the more obscure tags related to Sitemesh.  Currently, Grails’ Sitemesh integration is not very well understood by the community at large and I wanted to spend some time on it since Sitemesh is such a powerful part of the Framework.

I was hoping to spend some more time polishing this slide deck, but hopefully this presentation skeleton is helpful to the community as it is.  I am hoping to give this talk again at Gr8Conf in the USA this upcoming April and spend some more time creating more concrete and digestible examples.

I asked a question on the GUM (Groovy Users of Minnesota) User list about how to achieve a user/machine specific config.

I didn't have much time to figure it out but this is what I ended up finding out:

Grails 1.1.1 create-app generates a Config.groovy with this as the first few lines that would have told me what I need to know if I actually took the time to read it:
// locations to search for config files that get merged into the main config
// config files can either be Java properties files or ConfigSlurper scripts
//
// grails.config.locations = [ "classpath:${appName}-config.properties",
//                             "classpath:${appName}-config.groovy",
//                             "file:${userHome}/.grails/${appName}-config.properties",
//                             "file:${userHome}/.grails/${appName}-config.groovy"]
//
// if(System.properties["${appName}.config.location"]) {
//    grails.config.locations << "file:" + System.properties["${appName}.config.location"]
// }

So in my case all I had to do was put this in Config.groovy:
if (new File("${userHome}/.grails/${appName}-config.groovy").exists()){
    grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]
}

which allowed me to override properties by doing something like this in my ~/.grails/${appName}-config.groovy :
username = "sa"
password = "sekret"
// environment specific settings
environments {
    development {
        dataSource {
            dbCreate = "create-drop" // use your imagination...
        }
    }
}

I also ran across a little gem that you can do the same type of config merging with your BuildConfig.groovy by implementing a ~/.grails/settings.groovy file. (yes its hardcoded rather than a config.locations property in BuildConfig.groovy – see BuildSettings.groovy for more)

Now I really wish there was a way to set defaults for things like server.port in the configs.

Thanks, Ted Naleid, Scott Vlaminck, and Robert Fischer for helping me find what I was looking for!

SpringOne2gx was a blast this year.  It was great to get to know many members from the community!

I was able to record the Grails BOF (Birds Of a Feather) session at SpringOne2gx this year: Download it Here (80MB)

Big thanks to SpringSource and No Fluff Just Stuff for putting together an awesome conference!

Props to Dropbox for allowing me to share this recording.

Wow, Big news for the Groovy and Grails Community!  VMWare has announced that it is acquiring SpringSource.  Rod Johnson, the founder of SpringSource and Initial author of the Spring Framework also posted his thoughts on SpringSource’s blog calling it ‘SpringSource – Chapter Two’.  I don’t think that too many of us saw this one coming.  Now its time to wait until Oracle acquires VMWare If Marcel Overdijk’s prophecy is true

I’m not that familiar with SpringSource’s offerings, but It does seem like some of VMWare’s products are a natural extension to the goals that SpringSource is trying to accomplish with their Build / Run / Manage mantra.  The two companies don’t really compete, but VMWare + Grails seems like a good combo to me   Jerome Gagner blogged about how VMWare should throw in some terracotta for some extra spice to take on (read ‘out’) Windows Azure.

I must say that PaaS offerings look really appealing to me as a developer.  Even though I *can* manage machines and hardware, I don’t want to have to take on the risks and responsibilities.  I’m not quite sure what they are going to accomplish together but VMWare + Grails + SpringSource Technologies as a PaaS solution sounds good to me.

Sierra Bravo is putting on an overnight website challenge tomorrow featuring 12 teams and 12 non-profits.  The challenge is a great way to give back and strut our stuff.

I’m on a team called the Groovy Goolies and we plan to use Grails to deliver a powerful web-app.  Our team has an excellent lineup with a broad range of experience and talent.  I’m sure we’ll do great – we’ll definitely get to beat my friends on the Inetium Team.   The rich set of Grails plugins, excellent testing support and the power of Groovy will go a long way.

Checkout another post from another team-member or follow us on twitter.

Last night at the Groovy Users of Minnesota (GUM) meeting we did an IDE shootout where we covered Groovy and Grails support in the more popular IDEs.

Jesse O’neill-Oine from Refactr started us off with TextMate. 

I (Colin Harrington) presented on Eclipse and Netbeans:

Hamlet D’arcy teamed up with Matt Abrams & Bob Schultz to close out the night with Jetbrains‘ IntelliJ-IDEA.

Ironically IntelliJ-IDEA 8.1 was released the very next day.  Hamlet has some good tips on his blog about Intellij-IDEA.

This is an ever improving topic and changes very rapidly, so If we missed anything just drop us a comment

Special thanks to Guillaume Laforge, Petr Hejl, Sven Haiges of the Grails Podcast as well as everyone who has contributed to the community via blogposts, documentation updates, etc.

Enjoy.

Rather than implement properties in the Java Language, we have a convention called a Java Bean.  This basically means that properties are implemented with getter and setter methods with a PascalCase property name in the method among a few other simple conventions. 

Grails makes it incredibly easy to manage domain classes since it is inherently domain-centric.  When you need to enhance your Domain classes at the core of your application, you have an option of implementing your own getters and setters.   I love that by default you do not have to implement your own setters, but you have the power to do so if you wish;  the principle of sensible defaults.  Here is an example of a Book Object with two properties, author and isbn.

class Book {
    String author
    String isbn
}

Consider the case where a Book is in your Database with the ISBN of 978-1430219262 and a user tries to search for "9781430219262".  Unless you do some searchable magic, the user will not find the book.  A simple solution fo the issue would be to never store ‘-’ in the databse.  to make this happen you could easily remove the dash in the setter.  So your domain would look like this:

class Book {
    String author
    String isbn

    void setIsbn(String i) {
        isbn = i.replace('-','')
    }
}

When I first tried this, I failed a few times before I got it right.  Maybe I was just spoiled with Groovy’s groovyness, but I started out writing
def setIsbn(i){ ... }  and when that didn’t work: void setIsbn(i){ ... } which was being called, but never actually set the property.  Then I had a forehead smacking moment where I realized that the method signature must precisely match the signature of a JavaBean setter like public void setPropertyName(Type propVal) { ... }  In my case I had to make sure that the method was public (public by default), has a return type of void (which is not the default behavior of a closure), and the parameter passed in was of the same type as the property (String)

And then I blogged about it — the fourth day.

This last April I did a presentation at the Twin Cities Code Camp on Microsoft Silverlight and SOA with a Grails server.  I ended up writing a simple Grails application that used several web services to communicate to an in-browser Silverlight application.  I specifically wanted to show a Silverlight application interacting with non Microsoft Technologies.  I developed the Grails application on Linux on a different physical machine than what I used to develop the Silverlight application.

One of the Issues I ran into was that I was unable to make requests to the XML Web Services in the Grails application.  It puzzled me for a minute until a quick Google search turned up a simple issue: I needed a crossdomain.xml policy file (or the clientaccesspolicy.xml).  Flash/Flex users run into this all the time and thus most of what you will find is Flash centric.  What is the crossdomain.xml file?  Well its a way of restricting the domains that can access services.  Its basically a white-listing of domains that are allowed to access the services.  The browser and in-browser applications are supposed to respect the crossdomain.xml, and sometimes the Services (server-side) may protect themselves.  You can think of it as a robots.txt for Web services.

Great, I knew what the problem was, now how do I fix it?  I tried a few things, deploying to tomcat, but that didn’t work for me while I was actively developing the application.  Once I understood a little more about Grails and Jetty, I realized that I could just modify the Jetty server that launched when invoking grails run-app.  I simply had to add another context to Jetty, and bingo it worked.  Here is what I did:

I found Grails’ RunApp.groovy script (the one that gets invoked on grails run-app) which was located at $GRAILS_HOME\scripts\RunApp.groovy. (%GRAILS_HOME%\scripts\RunApp.groovy for you Windows folk ).  I had to simply create another context much like the Grails application context was being created.  Here is a stripped down example of what RunApp.groovy looked like. (modifications in Bold)

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
/**
 * Gant script that executes Grails using an embedded Jetty server
 *
 * @author Graeme Rocher
 *
 * @since 0.4
 */
...
grailsContext = null
rootContext = null
...
target( configureHttpServer : "Returns a jetty server configured with an HTTP connector") {
    ...
    setupWebContext()
    setupRootWebContext()
    server.setHandler( webContext )
    server.addHandler( rootContext )
    ...
}
target( setupRootWebContext: "Sets up the Secondary Root Context"){
    rootContext = new WebAppContext("${basedir}/web-app-root","/")
}
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


Most of the magic is in the rootContext = new WebAppContext("${basedir}/web-app-root","/") line.  Notice that I had to create a new folder ‘web-app-root’ which resided alongside web-app (I think I used web-app for a while too).  So this context responds to everything in the "/" domain which is the root of the site.  Once I put my crossdomain.xml file in that folder, I could access http://localhost:8080/crossdomain.xml and the services were then accesible via Silverlight — Yay!

I’m sure there are better ways of doing this, but this is what I did to get the job done.  Thanks to JT Dev for his most recent post, which reminded me that I was going to blog about this.  I basically did Solution #2 in his blog post on creating multiple jetty contexts.  Where was this post back in March?  Thanks JT for tipping me off to the Static Resources Plugin!

This past weekend I spoke at the Twin Cities Code Camp.  It was a Blast.   My Presentation was Microsoft Silverlight and SOA.  Its new technology so resources at this point are few and far between.  Silverlight itself is only a a 2.0 Beta 1 stage.

During the presentation, I highlighted Silverlight’s abilities to consume and invoke web services.  I wanted to show cross-domain services calls where the server is a non-microsoft based application.

I developed a RESTful Server application in Grails on Linux. 

The demo Silverlight application is a Video Podcast Administration Application.  I specifically wanted to show several client side methods of invoking web services.  I didn’t want to focus on any fancy visual effects video transformations etc. 

Here is code for the Grails Server.

Here is the Silverlight Application code.

My Presentation is in a Google Doc.

I had a blast at Code Camp, It sounds like something I’ll probably do again.

I might also put a short video together to show its functionality for Inetium. I’ll be sure to post it here.

Cheers!