Introduction to Grails with Scott Davis at the Colorado Software Summit

Grails According to Scott, today's Java-based web frameworks are partial solutions at best. They're only solving one piece of the puzzle - you still need to manage persistence, deployment, etc. all by yourself.

We're moving into a new era of web frameworks. The expectation now is a full-stack solution. Grails is a fully integrated modern Java web application in a box. It contains Spring, Hibernate, Quartz, Log4J, Jetty, HSQL, JUnit and Ant. You're not limited to using Jetty, you can type "grails war" and create a WAR that you can deploy to any application server. In a single zip/tar, you get the whole thing - including the database and servlet container. You get a lot of good default for free, but you're not limited to those defaults.

What does "modern" in a framework mean? It means it uses Convention over Configuration - Grails autowires components together based on naming conventions. Struts 1.x uses Configuration over Configuration - the more XML the better.

The Wisdom of Crowds - why are the many smarter than the few? What is the wisdom of crowds when it comes to web frameworks. Struts is the wisdom of crowds when it comes to web frameworks. It's based on sound principles (MVC) and was written by Craig McClanahan. He was the architect of "Catalina" Tomcat 4 and wrote Struts shortly thereafter. David Geary was contributor #2 to Struts. It has a proven track record and has a 60%-70% market share. Struts must be the perfect framework - especially since it has such a great pedigree.

So what's wrong with Struts?

  • It's 7 years old
  • It's verbose and overly complex (reflective of the EJB 2.x era)
  • Splintered community: Craig moved on to JSF -> created Shale, then the WebWork merger
  • While Struts 1.x was an unqualified success, Struts 2.x can't seem to build that critical mass - it can't seem to reach The Tipping Point like Struts 1.x did

The Recipe for a Tipping Point: Contagiousness / viral, tiny "tweaks" to a proven model can yield big, disproportionate effects, the rise is not "slow and steady" - the effect is dramatic and immediate.

Ruby on Rails won the hype award. It's largely worth the hype, but it's not revolutionary - it's evolutionary. It has tiny tweaks to the proven MVC-driven approach: Convention over Configuration, Scaffolding and Unified Technology Stack.

The one thing that Rails is lacking is Java support. Grails, on the other hand, offers the same experience using known, proven Java solutions.

  • Rails => "replacement"
  • Grails => "upgrade"

Scott drank the Rails Kool-Aid for a while and enjoyed it, but found it difficult to switch from Ruby in the morning to Java in the afternoon. With Grails, he doesn't have to do as much context switching, as well as all the Java libraries are available - the ones you know and love.

You can drop groovy.jar into your classpath and write Groovy code. One nice thing about Groovy is you can rename your existing .java files to .groovy and they'll work just fine. Included Ajax support: Script.aculo.us and Protoype as well as YUI. YUI is battle-tested since it's used by Yahoo and very well documented. You can use "grails install-dojo" to install the Dojo toolkit. Grails has a wealth of plugins available at http://grails.org/plugins.

Now we're going to crack our nuckles and build some code - slides are over.

 grails create-app conference
 cd conference
 grails create-domain-class Speaker (add some fields)
 grails generate-all Speaker
 grails run-app

The impressive things about this set of commands is I was able to 1) download Grails and 2) run all these commands at the same time that Scott did. I was definitely impressed (I knew I would be). Auto-scaffolding - you can get the same thing as "generate-all", but it generates controllers and views at runtime in-memory. All you need to do is create a domain object (i.e. Talk) and then create a TalkController that has the following line in it:

def scaffold = Talk

As a test, I tried this at the same time that Scott did and got the following error. It looks like Grails/Jetty isn't smart enough to pick up new classes as they're added.

[263102] commons.DefaultGrailsApplication Class not found attempting to load class Talk
java.lang.ClassNotFoundException: Talk
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)

Grails comes with a number of environments. Dev (the default) auto-reloads changes to Controllers, Views and even the Model (this is helpful for rapid development). Prod loads all items statically for maximum performance. To change the environments - you can change DataSource.groovy.

For some reason, adding/removing some properties on my Talk object and my application hasn't been the same since. Now when I try to access my TalkController, I see the following stack trace:

org.springframework.orm.hibernate3.HibernateQueryException: could not resolve property: difficulty of: Talk; nested exception is org.hibernate.QueryException: could not resolve property: difficulty of: Talk
	at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:640)
	at org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:412)
	at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:378)
	at org.springframework.orm.hibernate3.HibernateTemplate.executeFind(HibernateTemplate.java:342)
	at org.codehaus.groovy.grails.scaffolding.DefaultScaffoldDomain.list(DefaultScaffoldDomain.java:112)

I asked Scott about this error and he proved that removing properties from domain objects should work. I told him restarting Jetty didn't fix the problem and he suggested dropping the "Talk" table and letting Grails re-create it. Unfortunately, I have no idea where this database is, so that's difficult to do. Doh - now I realize what was causing the problem. Before I dropped the "difficulty" property, I had clicked on the column and that property was still referenced in the URL. When I'd refresh the browser, the stack trace occurred. I don't know if I'd consider this a bug or not.

dbCreate = hibernate.hbm2ddl.auto is used. When in development create-drop is used. In production and test environments, it uses update and saves the data between restarts.

You can turn off Hibernate's automatic schema alteration by commenting out "dbCreate" line in DataSource.groovy.

To run your application in Tomcat instead of Jetty, you can run "grails war" and copy the WAR to Tomcat. The WAR is created with the production environment by default, so you may need to pass in arguments or set environment variables if you want the WAR created in dev mode.

At this point, my battery died. Scott continued to cover how to order form elements (when using scaffolding) with "static constraints" and how to add validation rules. It was an excellent presentation and Grails definitely looks like a really cool web framework. The best part is I learned most of what you need to know to use it - in an hour!

I might have to try Grails soon - I love the concept of Life above the Service Tier and Grails would work nicely for serving up REST. I think YUI, GWT-Ext and Flex are probably the best frameworks for developing a SOFEA client. The question is - when using YUI, how do you download all pages in the application at once?

Posted in Java at Oct 25 2007, 07:03:42 PM MDT 19 Comments
Comments:

Matt:

A friend showed me Grails and he had made this application and it was quite impressive, but I want to know what Rails, Grails, etc. does that AppFuse (Java) couldn't do? I think the complex-relationships are where the effort needs to be.

If I want to create an application that has no relationships, I can find all these technologies that solve the same problem. What I haven't seen is a really simple and coded solution to a complex application. All the hairy applications have complex relationships and the clients don't care about the stuff we care about, they seem to care about their stupid scenario and using the application the way they want to use it.

We're using Struts1, Spring, Hibernate, and some AOP on the big project I'm working on. The design is okay, but overall the application is complex due to steady short term development and no design reviews of the architecture.

I guess I just don't see any of us selling clients on the use of this new whiz-bang technology. I think proving the scalability and a proven-track record will be what they check-signers will be looking for. I started Rails, bought the book, did a couple applications, and then ... I thought. What do I really like to do? Java.

Rails is pretty elegant, and don't you think that Grails is just a rip-off? Can it be as efficient as Rails if it's a copy of the Rails concepts? I'm not sure. And, I do appreciate all the work it must have taken to get Grails off the ground.

I'll keep listening and maybe I'll try it when life slows down.

Posted by David Whitehurst on October 25, 2007 at 09:08 PM MDT #

Awesome article on Grails. We are going to use it in our next project. It is amazing how much you can achieve with much fewer LOC. And all of it is based on proven Java libraries.

Wanna use JPA, Lucene or Acegi? Everything is no problem.

And with Intellij 7 you can debug/code-complete it just like you would do it with Java.

Posted by Sakuraba on October 26, 2007 at 12:35 AM MDT #

> don't you think that Grails is just a rip-off? Can it be as efficient as Rails if it's a copy of the Rails concepts?

Come on. It can't be as efficient because it was inspired by it? Whatever issues one might have with grails, that's a little silly.

Posted by Luke Daley on October 26, 2007 at 01:52 AM MDT #

and don't you think that Grails is just a rip-off? Can it be as efficient as Rails if it's a copy of the Rails concepts?

The Rails concepts are cloned in so many languages. Just look at Symfony at the PHP side. Does that mean all of those clones are worthless? Hell no. If a technology borrows highly successful concepts and provides easier integration with your existing platform, then thats a big win.

Besides, Grails does not use a "ActiveRecord" Pattern, it is based on Hibernate 3. Or if you have existing JPA classes, you can just use them instead. So it is not just a "rip-off".

Posted by sakuraba on October 26, 2007 at 01:57 AM MDT #

Wasn't Java inspired by C?

Grails is a fantastic framework and, as Matt points out, Rails is a replacement as Grails is more an upgrade. As we know by now, Java EE has failed in web development because it's just too complex for simple things. Thanks to AppFuse, we still managed to create web sites, but oh boy, so many frameworks to learn, so many incompatible APIs... just for CRUD operations. Grails is showing its strength as a web framework, but dive into it and you'll see that it's also a fantastic fwk for back end too (business rules, DSL, integration with WebServices and so on.

Posted by Antonio Goncalves on October 26, 2007 at 05:39 AM MDT #

Java EE has failed in web development because it's just too complex for simple things.

wtf?

Posted by Anonymous Coward on October 26, 2007 at 07:16 AM MDT #

Actually, Grails can be much more efficient than Rails. Rails is written in Ruby, which is a wonderfully expressive language, but not all that fast. Most of Grails is written in Java, which is comparable in speed to C++ (if you don't believe me, upgrade to Java 6 and try again).

Rails showed us the way, but for folks like me who are mired in Java, Ruby/Rails just isn't feasible. I need something that can *seamlessly* coexist with Java, not replace it.

If you aren't convinced yet, well, that's okay. It's rational. You should always be sceptical when someone promises you a silver bullet that will solve all your problems. Because we all know by now that silver bullets don't exist - they are all a marketing ploy. Well, all except this one, which is still a lot of marketing - but there is some real substance in Groovy/Grails.

I would ask you to suspend your disbelief for maybe a week, just in this case. Download this stuff, try it out, and then decide. Even if it doesn't solve all your problems, I promise you it will be the most fun you've had with software in a while.

Posted by Jason Smith on October 26, 2007 at 07:43 AM MDT #

[Trackback] Dans son dernier billet, Matt Raible, un ténor de la communauté Java, livre ses impressions sur Grails. Il a pris en pleine gueule une présentation de Scott Davis, autorité non négligeable du la planète Groovy. Un des points important, que Matt...

Posted by JS Bournival on October 26, 2007 at 10:11 AM MDT #

Matt, I was and still am a big fan of Appfuse, but I'll have to admit my preference is moving towards grails and even jruby+rails.

Posted by Tom on October 26, 2007 at 10:27 AM MDT #

I'd like to suggest that responses to David Whitehurst need to be tempered rather than heated. He has an opinion that he obviously believes in, and he has every right to ask the question. If you disagree, rather illuminate the issues for him so he can understand. Let's not shoot the people we would like to convert.

David, my personal take on Grails having used it for some time now, and having come from Struts, then Webwork in terms of web frameworks, and having played with Rails to some extent, is that while Grails borrows from some of the philosophies of Rails, it does not borrow from the underlying design and implementation. So absolutely it can be a lot more efficient than Rails, particularly because it actually uses proven enterprise technologies like Spring and Hibernate, to name just 2.

This is not a sledge at Rails. For those invested in Rails, by all means, have at it. But for those of us with a significant investment in Java, Grails is a perfect fit. For me I've just been astounded at the productivity that Grails has brought me. I initially started working on a 'toy app' to learn Grails, and as I made the application more and more complex, I expected Grails to hit a critical mass at some point. But it hasn't, so much so that the toy app I've been using to learn with, I'm now quite close to using to start a small business. I still have some concerns about the reliability of Grails in the field, but it's mostly a perception issue because as I said, at the end of the day, the underlying technology is Spring and Hibernate etc, and they are proven in the field.

I can't argue about AppFuse since I never used it but for somebody who has felt the pain of Struts, felt the frustration of Webwork (in that it was constantly a moving target that then got 'assimilated'), Grails is a breath of fresh air in terms of development. It allows me to focus on solving the business problem, not the technology problem - since there is not technology problem.

Anyway, that's just my experience. YMMV. At the end of the day comments by people like David should be addressed graciously. Otherwise you're going to lose credibility since it becomes emotional and not logical/rational... which technology decisions should be.

Posted by Darryl Pentz on October 26, 2007 at 02:52 PM MDT #

I want to comment here that I didn't mean to spin anyone up. In fact, I just feel that everytime someone comes up with the next greatest thing, the hype takes over. I keep rolling over and over in my head a question that I need to answer and that's "do I want to be an expert in anything or allow my interests to take over and keep trying to evangelize the next greatest web design language and framework for enterprise apps.

Like Darryl said, I think Hibernate and Spring are proof positive that they perform. And, my "rip-off" statement was more along the lines of trying to focus attention on something else using "rails" in the name. I really like Matt's AppFuse and I work with it but I leaning toward figuring out the "whole" package thing. I've recently did a rather healthy PHP ecommerce site from scratch and I have to say that PHP sucks IMHO. It works but I just don't like it.

Java I like :-) And, the PHP thing has caused me to develop a way to discuss web site development and gather requirements that allow me no guessing. When I have drafted these I may go public with my thoughts and then use the checklist, procedure, whatever, to bid on a large J2EE project and then by my authority work to discover the absolute best web framework and development methods. I still think Struts, custom tags, and now AJAX is the ticket. This again, is just my opinion. And, yes, I'm opinionated. I probably have severe ADD or ADHD and every time a new whiz-bang thing comes out I'm up late playing with the download. I'm getting a little more focused in my old age. So, I'll let the late-nighters play with Grails and when I hear the big boys employing development teams using Grails I may, and only then, try it myself.

I'm partial to AppFuse and I won't jump ship. I have some ideas for some new features for AppFuse and it just means that I have to find the time to employ them. Matt has the right idea with AppFuse, let's see how 2.0 works out. The proof is in the pudding. :-) David

Posted by David Whitehurst on October 26, 2007 at 06:15 PM MDT #

David, and I think there's nothing wrong with that (your loyalty to AppFuse). I worked with the Java web frameworks I mentioned earlier, and I worked alongside other guys who were doing ColdFusion, and the ease with which they put together their dare I say robust web applications was always a jealousy point. I soothed myself with the knowledge that Java, while requiring more hands-on 'wiring up', carried better enterprise capabilities, so all that extra stuff was worth it. Of course, here we're really just referring to the domain of web applications specifically. But as I say, I always felt there had to be a better way to accomplish what we were trying to accomplish. It was around this time that Mike Cannon-Brookes of Atlassian fame had posted his "Who needs EJB's?" blog post that got so much attention, and there I was thinking, "is this stateless session bean really necessary?". When I later tried Ruby On Rails (primarily to see what all the fuss was about) I found myself thinking "this is how web development should be like". Not to argue about ActiveRecord as a design approach, but the way that everything had a specific place, that convention was preferred over configuration. Opinionated software. I liked it, and I found myself wondering "why doesn't Java have this?". Not much later I found Grails, and I haven't looked back since. I agree that the hype factor is frustrating. I still feel there was never a need to make the radical change from Webwork 1 to Webwork 2 - the whole XWork + Webwork layering nonsense. There I was often needing to relearn ways to accomplish things that worked just fine in Webwork 1. It was very annoying. Hopefully Grails doesn't go that way and we get some consistency.

Posted by Darryl on October 27, 2007 at 01:15 PM MDT #

In my opinion, Scott Davis is the best speaker on the NFJS tour. Not that Grails and Groovy aren't great, but he could make people get excited about Struts 1 if that were the topic of his talk. I must admit that even after being pumped up about Grails, I haven't tried it out, but I use Groovy every day now and simply cannot get enough.

Posted by Dan Allen on October 28, 2007 at 10:09 AM MDT #


I think the central point of Grails (and Groovy) is that they can use Java libraries and java code seamlessly. For Enterprise developers especially, this means integration with their existing code bases. It also means, as others have mentioned, that you can get basically anything else as a library. This is the Goovy/Grails killer point for me.

I have just started using Grails and I am finding, however, that it is not quite ready for prime time yet. It is about to get to version 1.0 but there are still some large holes I see from reading through the forums. Primarily (for me) the lack of support for "many to many" relationships in the database. Working in a web 2.0 world "everything" is related so this is key. The old web 1.0 simple stateless model is past its sell by date.

My concern (and I am learning as I move forward with Grails) is that as soon as I move beyond anything like the tutorial apps in complexity the framework model will give way to manual configuration.

Most languages are reasonably mature now, to the extent that the language does not really matter, what matters are the available libraries, frameworks for automation and community for help. Grails scores : A, B, C right now imho (framework needs to get to v1.5 and community is not so large yet)

Posted by Ian Wilson on October 28, 2007 at 06:30 PM MDT #

Ian,

Grails has supported many-to-many relationships for some time now. If you have a particular issue with a domain model I suggest you raise an issue. There are 2 ways to implement many-to-many in Grails. One way is with an assocition class:

class Group {
   static hasMany = [membership:Membership]
}
class Membership {
   Group group
   Person person
}
class Person {
   static hasMany = [membership:Membership]
}

In this case we use the Membership class as the association class. The other way is to let GORM handle the relationship for you:

class Group {
   static hasMany = [people:Person]   
}
class Person {
   static hasMany = [groups:Group]
   static belongsTo = Group
}

In this case one side of the relationship has to take responsibility for managing the relationship. In this case since Person belongs to Group, the Group class plays this role. This is exactly the same as Hibernate which requires one side of a many-to-many to act as the inverse.

As I said if you have any issues with this raise an issue in our JIRA.

Posted by Graeme Rocher on October 29, 2007 at 02:53 AM MDT #

Uhh,

Rails has no java ? How about running Rails with JRuby then ? With heavy investment from Sun and IBM I truly see this as a viable option as well.

Later
Leo

Posted by Leo on October 29, 2007 at 09:22 AM MDT #

(Graeme, Ian,)

Just to add to the Grails many-to-many info. While GORM supports many-to-many, the dynamic scaffolding does not. And from what I gather, it won't be fixed until after 1.0, unfortunately. I can only hope others consider this a high priority. For now, I am using an intermediate class.

There are other issues like this that you can expect to bump into given the youth and scope of the project. One challange I am having is the lack of good current documentation and non-trivial examples. Hopefully after 1.0 is released, this will start to improve.

That said, my experience so far is that Grails is more productive and a better starting point for common CRUD web applications than any AppFuse options. I highly recommend you check it out.

I do think frameworks like Wicket have advantages over Grails and other MVC style frameworks. But Grails is much easier to get started with for anyone experienced in web apps. And much of the benefit comes from the full integrated stack. If only Grails had been built on something like Wicket instead of SpringMVC, I could have it all. Maybe Grails 2.0 will give us that. Mostly we just need Wicket components that can accomplish the dynamic scaffolding for GORM. With that you'd have the quick start of Grails and the benefits of UI components.

Posted by Steve Tekell on October 29, 2007 at 02:59 PM MDT #

@Steve Take note of the Grails-Wicket plugin: grails-wicket plugin link

I haven't tried it yet... I'm still getting up to speed on Wicket in it's own right and haven't done much with Grails.

Posted by Clark Updike on November 02, 2007 at 01:51 PM MDT #

Leo.... I totally agree I've always wondered why more don't explore this options.

I use Grails at work and Rails at home.

Outside of the java vs ruby performance (and there are options like Ruby Enterprise or Jruby etc). I'm on the Rails side through and through. To start Groovy is like ugly ruby!!! (I never really liked java, and groovy is better. But I definitely perfer writing ruby). I think Rails still leads the way, things like the asset pipeline & jquery they were quick to move on and try to integrate better into the framework.

I like how integrated testing and deployment are. Rails just does a great job of thinking big picture!

Really unless you have an existing java app with a good number of developers. I don't see much reason to go with Grails over Rails (honestly what the likeliness of getting loads so big ruby can't keep up, if you do get that big, you can have someone deal with scaling. There are giant websites: yellowpages, twitter, groupon running rails, so it obviously can scale).

Posted by Braden on July 06, 2012 at 03:19 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed