text: Introduction to Grails with Scott Davis at the Colorado Software Summit
  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.
  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 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 #
  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 #
  Posted by JS Bournival on October 26, 2007 at 10:11 AM MDT #
  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 #
  Posted by David Whitehurst on October 26, 2007 at 06:15 PM MDT #
  Posted by Darryl on October 27, 2007 at 01:15 PM MDT #
  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:
  In this case we use the Membership class as the association class. The other way is to let GORM handle the relationship for you:
  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 #
  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 #