RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Going Live with a Grails-Powered Blog : Page 5

Once you have built a Grails project, how do you deploy it? Learn how to use Groovy builders, filters, and tags to deliver a Grails project. Along the way you'll delve into AJAX and deploy a Grails application in Tomcat.

Packaging and Deploying the Blog Application
You now have a blog application that will allow you to create blog posts, receive comments from the readers, publish the details of the posts via RSS, and manage the posts through tagging. It is time to think about deploying it! For this, you need to install Tomcat and MySQL. You will have to package the application as a WAR and tell it which database to access.

The grails war script will package the application as a WAR. Go to the command line and run this script. It should create a war file called groovypublish-0.1.war. The version number comes from the application.properties file. To generate a WAR without the extension, simply specify the name you would like to call the file after the script command:

grails war groovypublish.war

Pick Your Grails Environments
Grails has a built in notion of environments. The default environments it understands are development, test, and production. A Grails application will always run within the context of a particular environment. The default when running grails run-app is the development environment. The default when running grails war is the production environment. It is possible to change these defaults by specifying the environment before the script to run. The following script:

grails prod run-app

Will run the application in production mode, while this script:

grails dev war 

will run the application in development mode. You can also create your own environments and run Grails under them using the grails.env system property. This script:

grails –Dgrails.env=uat run-app 

Would run the grails application in UAT mode.

So what do all these environments mean? The biggest affect they have is on the way the application connects to the database. Take a look at DataSource.groovy in the conf directory. If you haven't modified this already, it will look something like Listing 11.

The dataSource setup at the top of the DataSource.groovy file is the common data source configuration for all environments. You can see that the other "environmental" data sources specify only the dbCreate and url properties. The dbCreate property is the only one here that is specific to Grails rather than a JDBC data source. It offers three database modes:

  • create-drop: this drops and recreates the database when the application is started.
  • create: this creates the database if it does not exist, and deletes the existing data if a database does exist.
  • update: this creates the database if it does not exist and modifies the structure of it if it does exist.

The only option that does not delete all the data in the database is update. Make sure you use this when you deploy the application. Notice that the production environment comes in update mode by default.

In the example above, Grails was run in UAT mode by using the grails.env system property. If you wanted to set up a database for this environment, you could add the following to the DataSource.groovy file:

uat {
  dataSource {
    dbCreate = "update"
    url = "jdbc:hsqldb:mem:uatDb"

The Hibernate properties specified in this script can also be environmentally aware. If you wanted to enable SQL logging in development only, then you could add the following:

development {
  dataSource {
    dbCreate = "create-drop" // one of 'create', 'create-drop','update'
    url = "jdbc:hsqldb:mem:devDB"
  hibernate {

Using a Real Database
Install MySQL and create a database like so:

CREATE database groovypublish;

GRANT ALL PRIVILEGES ON groovypublish.* TO 'groovypublish'@'localhost'

This will give you a database called groovypublish with a user called groovypublish and a password of groovypublish. When configuring the Tomcat instance, you should set up the data source in JNDI. This allows the container to manage the database connection rather than having to specify these details in the application. Create a JNDI data source called groovyPublish/dataSource and configure the Grails application to use this data source when running in production mode by updating the DataSource.groovy script:

production {
  dataSource {
    dbCreate = "update"
    jndiName = "java:comp/env/groovyPublish/dataSource"

If you now repackage the application and drop the WAR into Tomcat, you should be able to access the application through Tomcat directly.

Controlling BootStrap
One last change needs to be made to the BootStrap script, which is to allow it to run only in development. Otherwise, it will run every time you try to start Tomcat. You can simply wrap the bootstrap code with this:

if(grails.util.GrailsUtil.environment == "development") {

Tapping the Power of Groovy and Grails
You have now created and deployed a blog application. You obviously can make further improvements to the application, but you can see just how powerful Grails is and how easy it is to build applications using Groovy and Grails. The code used for these articles has formed the basis of an open source project that I intend to continue. To see how it progresses, or to get involved, contact me or take a look at the site.

Jon Dickinson is the principal consultant at Accolade Consulting. He focuses on helping organizations improve the software they deliver through agile development techniques.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date