The key turned out to be the discovery of the DefaultGrailsDomainClass . This class performs a series of introspections on your domain objects, and allows you to programmatically access quite a bit of information on them. For example, suppose we had the following domain object:

class Pizza{

String name

BigDecimal diameter

List toppings

hasMany = [toppings:Topping]

}

Class ‘Pizza’ contains a name / description, diameter, and a many-to-many relationship with the ‘Topping’ class (although not defined here). Nice and simple… now, the good stuff.

By passing a Domain Object class to DefaultGrailsDomainClass, we can access a good deal of info about that Domain Object. Among other things there are methods to access a Map of the constraints, determine whether or not a property is a relation (1:1,1:m,m:m), and access the properties directly by obtaining a set of GrailsDomainClassProperties . Of particular use to me is the DefaultGrailsDomainClass.getPersistantProperties() method, which returns a GrailsDomainClassProperty List of all the properties that are persisted to the database. That’s pretty excellent.

To illustrate this, let’s get the persistent properties for a Pizza:

pizzaProperties now contains a list of ‘DefaultGrailsDomainClassProperty’ objects. If we iterate through them, we can see the following information:

Think of the possibilities of what can be accomplished by programmatically accessing the properties on your domain object! However, I am not exceedingly clever:

else{//do something clever!}

}

}

The exportClassSingle method above accepts the ConfigObject which will be populated with the domain object’s data, the name of the class, and an instance of the domain object. It is relatively simple: it takes the class, loads its persistent properties, loops through through them and if the property is not an association, it is added to the config object.  By repeatedly calling the method for each of our Domain objects, we build up the ConfigObject which contains class and instance data. The preExportClean() method looks for and escapes any usage of ‘$’, which can cause some odd behavior if not escaped. We ignore associations here because in the real app, everything is connected to one root object; if there were associations among the child objects that we wished to capture then the above method would be quite different.

Given the following DSL:

pizza{

pizza_0{

name="Small"

diameter="8.0"

}

pizza_1{

name="Medium"

diameter="14.5"

}

pizza_2{

name="Large"

diameter="21.0"

}

}

and assuming it’s saved in a String called ‘pizzaDSL’, we can import this data into our system using the following steps:

ConfigObject config = new ConfigSlurper().parse( pizzaDSL )

The ConfigObject config now contains a map of ConfigObjects. Using the key of ‘pizza’ returns a map of 3 more ConfigObjects.

2. Construct objects using the configObject.

config["pizza"].each{key,map->

Pizza p = new Pizza()

p.properties = map

//set toppings

p.save()

}

3. Celebrate

Well, that’s it. I hope this helps explain the usage of the Default Domain Class and that you all find a usage for it.

This may sound esoteric, but to someone doing plugin development in Grails, it’s a life saver, and here’s why.

When building a plugin for Grails, the plugin itself is built as a Grails application. This has many benefits, including in some cases being able to run the plugin and test controllers and domain classes directly in the running plugin. However, most, if not all plugins are intended to plug into another Grails application. Given that, the only real way to test the usability of your plugin API, and whether the plugin works in the context of larger Grails application, is to install the plugin into another Grails application. Here’s an example:

1. I’m developing Plugins A and B to be installed in a new Grails CMS application I’m building
2. Plugin A depends on Plugin B to function
3. Once Plugin B is in good enough shape, I’ll install it into Plugin A using the Grails install-plugin command
4. Once Plugin A is in good enough shape, I can install it and Plugin B into my Grails CMS application
5. After testing the CMS for a while, I discover a bug in Plugin B which also requires a small change in Plugin A to accommodate the bug fix (are you still with me?)
6. I fix the bug in Plugin B and repackage
7. I remove Plugin B from Plugin A and install the latest version of Plugin B into Plugin A to make the changes required in Plugin A and repackage
8. In the CMS application, I remove both of the plugins and reinstall both Plugins into the CMS
9. I become tired of installing and uninstalling plugins and go out for beers

With Grails 1.1, this development cycle is improved drastically. Now, during development you can provide explicit locations for Grails plugin projects, without needing to install the plugin, to develop against that plugin. Here’s an excerpt from the Grails 1.1 release notes:

An application can now load plugins from anywhere on the file system, even if they have not been installed. Simply add the location of the (unpacked) plugin to you BuildConfig.groovy file:

// Useful to test plugins you are developing.
grails.plugin.location.jsecurity = "/home/dilbert/dev/plugins/grails-jsecurity"

// Useful for modular applications where all plugins and
// applications are in the same directory.
grails.plugin.location.'grails-ui' = "../grails-grails-ui"

This is particularly useful in two cases:

1. You are developing a plugin and want to test it in a real application without packaging and installing it first.
2. You have split an application into a set of plugins and an application, all in the same “super-project” directory.

Now if you want to test your plugins in the context of a larger application, you can do so without the pain of constant reinstallation.

Fortunately, for a little while now, the Grails distribution has been packaged with an Ant macro, graciously contributed by LinkedIn, which allows you to more tightly integrate Grails tasks with an Ant build. You can find the script here:

http://svn.codehaus.org/grails/trunk/grails/src/grails/grails-macros.xml

This macro sets up a Java environment using the GrailsStarter and GrailsScriptRunner bootstrap classes to startup a Grails environment and execute the given Grails Gant script. This is similar to the way the Grails command line batch/shell scripts function, however the macro does it within an Ant java task, which allows us to add additional information to the JVM as it executes, such as additional classpath information, system properties, and JVM arguments to name a few.

You can use this macro by importing it into your Ant build script and invoking it as follows (assuming your GRAILS_HOME environment variable is set properly):

<import file="${env.GRAILS_HOME}/src/grails/grails-macros.xml" />

<grails command="clean" />
<grails command="war" args="mywarfile.war"/>
...

This is certainly handy but doesn’t offer much beyond using Ant’s exec task. However, once we look at what we can pass into the macro, the added value becomes more apparent. The macro accepts several argument attributes and elements to augment the way the macro executes. The example below shows how we can add additional system properties and classpath items to a run-app command.

<grails command="run-app">
  <sysprops>
    <sysproperty key="server.port" value="9999" />
  </sysprops>
  <extend-classpath>
    <pathelement location="SOME_OTHER_LIB_LOCATION/foo.jar"/>
    <pathelement location="SOME_OTHER_LIB_LOCATION/bar.jar"/>
  </extend-classpath>
</grails>

This example shows that we can add in system properties to specify to things like the server.port value for the run-app command. In this example it is hardcoded, however in most non-trivial Ant build processes, this would be specified via properties file or some other mechanism to provide values that are specific to the build environment in question (e.g., development, test, integration, production).

What’s more interesting in this example is that we’ve added additional elements to the classpath which then get passed along to the Ant java task. This provides tremendous flexibility to include items in the classpath that do not appear in the standard Grails locations like these:

• GRAILS_HOME\dist
• GRAILS_HOME\lib
• PROJECT_HOME\lib

This flexibility allows for other build artifacts in an Ant build process to be dynamically included into the Grails runtime from other locations in the build process.

It should be said that I’ve had to make some modifications to the macro in order to tailor it to my needs as well as to get it working properly across environments. You can see the changes I’ve made here.

You can check get the latest and greatest, as always, at grails.org.

1. Leave the Red5 functionality as a separate WAR and use a shared directory which the video plugin would deposit the encoded movies
2. Copy the war artifacts into the Grails plugin so the Grails app embeds the Red5 functionality within the WAR

I opted for the latter because I would like to have the Red5 application code use GORM to read meta data about the Movie asset. Additionally, to have a tight integration with Spring Security I would like to have the artifacts share the same application context. Finally, it is easier to debug code (btw, IntelliJ IDE rocks) if you don’t have to manage the startup of two different WARs. I’d like to say developing this plugin was easy, but in all honesty, it was a totally pain in the bum, and at the time, it seemed overly complex. In hindsight though, I realize that the reason for the “pain in the bum” was my lack of understanding of the life cycle of the context loader in Spring.

Once that hurdle was jumped, due to the tight Java/J2EE integration, the rest of the plugin development, installation scripts, custom artifact, etc. was ridiculously easy. The work was mostly setting up Spring configuration for the plugin. Because of how elegant the plugin architecture is, I think stitching together tiny pieces of functionality that is packaged in plugins is the best way to grow functionality base of Grails.

With this in mind I decided to release the Red5 integration work as a separate plugin and have the Video plugin depend on that for the RTMP streaming. So if one person doesn’t want to use all the Video plugin functionality they can at least use the Red5 Integration functionality. If you’d like to check it out please find it in the grails plugins section of our site. One thing to note is the Red5 plugin comes packaged with the source code for Red5.

I am going to send an email to the Red5 team and see if they will keep me abreast of new functionality as it comes down the road so I can maintain the plugin. I’ll keep folks posted on what they say. Finally, I’d like to thank, the Red5 team for the their 0.6.3 WAR release of the Red5 server and Alexander zhukov who created Red5-minimal. The fact that Alexander was able to accomplish what he did let me know it was “in theory” possible to incorporate the functionality in a plugin and gave me inspiration during the dark times. If you become the next youtube with this Grails plugin, throw a brother a couple bucks…. do the right thing

You can find information about the plugin on our Grails Video Plugin Page.

And as with the Amazon S3 Plugin, this is a very preliminary version, and we’re hoping to get some good feedback from the Grails Community and you on what we can do better. However, there may be some bugs that we haven’t quite gotten to yet.

Feel free to leave comments regarding the plugin on this posting. We know we have a lot more testing to do and features to add, so any feedback is most welcome.

In short, we wanted to build something that would manage static file assets such as images, movies, audio, Flash, and perhaps down the road, site backups, on the Amazon Simple Storage Service (S3). 

This is a very preliminary version of the plugin, and we’re hoping to get some good feedback from the Grails Community and you on what we can do better.  However, there may be some bugs that we haven’t quite gotten to yet. 

Feel free to leave comments regarding the plugin on this posting.  We know we have a lot more testing to do and features to add, so any feedback is most welcome.

I agree with Adam’s thoughts in his previous post and have been very impressed with the activity in the Grails community. I subscribed to the user mailing list. Each day I receive from this list anywhere from 40-60 emails from users running into various issues on projects and folks from the Grails community providing their suggestions or troubleshooting tips. The activity of user/developer mailing lists is one of the most important benchmarks in determining the health of an open source framework – along with supplied functionality (obvious), core technology, the architects driving the vision, commercial support, documentation, check-in velocity and discussion in the blogosphere. To give an indication of the acceleration of activity in the Grails community, in October 2006 the same mailing list was averaging around 5-6 emails – almost a 10 fold increase in one year.***

Also, last week on the Grails user mailing list, there was some spirited debate on the level of Grails documentation (or lack of it) and whether it was appropriate for the release level of the framework. The amount of documentation right now doesn’t really concern me. What struck me the most about the dialog was the intensity of the debate. It shows the community is excited about what has been developed, are passionate to help out in whatever way they can, and care deeply about the frameworks success. And the community’s passion/enthusiasm for Groovy/Grails is clearly indicative of the framework’s ability to meet a need and fill a gap, something the community is looking for. IMHO this enthusiasm will be the driving force of success and perpetuate Grail’s momentum. And while more formal documentation is sure to come down the road, I’ve found the answer to most of the issues i’ve run into by querying the mailing list. It has been an excellent source of living documentation. – http://www.nabble.com/codehaus—grails-f11860.html

Of course with every new open source project there is always a lot of user/developer mailing list activity in the beginning. The question always becomes: Does this activity last, does it have staying power? With over a year and half of Grails development under their belt, a pending 1.0 release, and the clear need for a rapid application development framework in the J2EE architecture landscape, I have the feeling Grails is here to stay. Now I’m just trying to find the best way to support the growth…

That being said, one of our goals here at Cantina will be to leave some tips/issues that we run into as we develop plugins for the framework. Although it will not be formal documentation – we get our kicks from developing functionality – there may be some issue/tips that we run into that can be helpful to you. And please feel free to weigh in by leaving a comment if you know a better approach.

*** fyi, this calculation was performed with a VERY informal last year inspection of the mailing list on Nabble

UPDATE – 10/31/2007

I guess I should be been paying attention to the email threads a little better… Two email threads -

http://www.nabble.com/number-of-people-companies-using-Grails-tf4721318.html

and

http://www.nabble.com/Mailing-lists-statistics-tf4693805.html#a13416495

also discuss the growing activity of the mailing list.

We’ve used Java here at Cantina on innumerable projects with a great deal of success. The toolset is very complete and Spring and Hibernate have been a godsend for allowing us to focus on the intellectual "meat" of a project. Then, in an effort to explore some new technology for a couple prototypes we were working on we found Grails.

I think the first thing that drew us (me) to Grails was the mantra that I heard over and over again at a talk given by Venkat Subramaniam at Sun a while ago regarding Groovy on Grails have more "signal to noise". Less syntactical noise, more code signal (i.e., the "meat"). In his talk he threw together an AJAX enabled form in about 10-15 minutes with all the CRUD and validation you need.

Once we started using Grails in house, it quickly became apparent how deep the mantra of having a greater "signal to noise" went. We love Spring and Hibernate but we hate XML configuration. Yes, XML is ubiquitous, very readable, and supported everywhere, but, as technologies like Spring and Hibernate put more of our application structure into XML, it makes it very hard to debug all of our application when some of the structure sits in very static XML.

Grails provides a great approach to this. Through the Grails BeanBuilder, you specify all of that lovely Spring configuration within a very readable and debuggable Groovy syntax. This makes for a much more powerful way to configure the structure of your application as well as allows you to actually step through parts of your configuration with a debugger.

Of course, Grails does a whole lot more than that (including a lot of the auto-wiring in Spring so that you don’t have to do any configuration), and here are just some of the things that caught our eye:

• GORM (Grails Object Relational Mapper): as if Hibernate wasn’t powerful enough, Grails adds some useful methods of querying and mapping your object model that go above and beyond Hibernate. With dynamic methods, you can query against properties of your object model classes (domain classes) via methods that you never have to write, like this:
  
  // Assuming you have a domain class called "Person"
  // with a name property and a type property that
  // can be "employee" or "customer"  

  def allPeople = Person.findAll() 
  def onlyEmployees = Person.findByType("employee") 
  def howManyEmployees = Person.countByType("employee")

  I didn’t have to write any of these find* or count* methods, they come free of charge with GORM which makes the simple queries a lot easier to manage.

• Auto-reloading: one thing that has always plagued us as Java developers is the development cycle of fix -> deploy -> start -> test. There are certainly ways to reduce this cycle in Java, but sometimes the project just doesn’t allow for it. Grails is built with the mindset that changes to most code assets should be reflected instantly in the running application, thus reducing the time it takes to test code changes
• TagLibs: Creating GSP (analogous to JSP) tag libraries requires much less code and no configuration to get your tags and and running
• Intellij IDEA Integration: I love TextMate as much as the next guy, but code completion and debugging are things I’ve just gotten too used to (call me lazy). The Groovy/Grails plugin for Intellij IDEA has come a long way towards making Grails a first class IDE citizen.
• Legacy Integration: A lot of the projects we work on involves an existing Java application and SQL database. There is often business logic already implemented in Java classes (Spring or otherwise) that really don’t need to be rewritten. Since, at the end of the day, Grails is Java, we can make use of the existing codebase in a way that is much more seamless than if we were to introduce another web technology. Also, the fact that it’s all Hibernate under the hood makes it easier to adapt a set of domain classes to an existing database schema. This makes Grails an easier sell on those technical re-architecture projects in the Java world.

Beyond the technology, there’s just a lot of momentum in the Grails community. Within the last year that I’ve been watching, Grails has gone from a 0.4 to just about 1.0 (I’ve been using PHP frameworks that haven’t bumped the minor version number in over 2 years). There’s a healthy and growing list of plugins (grails.org/Plugins) that seem to be addressing the core needs of new application development.  We’re really looking forward to the next Grails project and experiencing a lot more signal and a lot less noise.