:jasonrudolph => :blog

puts Blog.new(”nonsense”)

Out of the Box Grails + JEE Integration

Posted by Jason Rudolph on December 18th, 2006

There's something to be said for things that just work right out of the box, and JEE integration with Grails falls nicely into that category.  When people first hear about Grails and they see demonstrations of its rapid application development (RAD) capabilities, it’s not long before an air of skepticism seems to set in.  Surely a framework offering this level of productivity can’t possibly play nicely with a corporation’s highly-configurable and often complex application servers.  Of course, this isn’t a new topic, as we've certainly explored some of these areas before.  Nevertheless, questions remain, and any new technology has to prove its worth.  

One rather common question concerns the ability to hook into an app server’s data sources using JNDI.  If you've invested in a JEE container, there's a good chance you want to make use of its database connection pooling.  (For that matter, it's probably a company policy to do so.)  And, needless to say, beyond just connection pooling, using data sources also offers the added security and maintenance benefits of not packaging your database user ID, password, and URL inside your application.

So, what does it take to get a Grails app to obtain its database connections from a container-managed data source?  Assuming you have your data source configured in your app server, it’s as simple as telling Grails how to look it up.  Let’s first take a look at the data source definition in the app server.  For this example, we’ll look at a MySQL data source configured in JBoss Application Server.

projects> cat /Applications/jboss-4.0.5.GA/server/default/deploy/mysql-ds.xml
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
    <local-tx-datasource>
        <jndi-name>
jdbc/racetrack</jndi-name>
        <connection-url>jdbc:mysql://localhost/racetrackprod</connection-url>
        <driver-class>com.mysql.jdbc.Driver</driver-class>
        <user-name>prod</user-name>
        <password>wahoowa</password>
        <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
        <metadata>
            <type-mapping>mySQL</type-mapping>
        </metadata>
    </local-tx-datasource>
</datasources>

Once we know the JNDI name for the data source – in this case, we see from the output above that it’s jdbc/racetrack – we simply define a Spring bean for that data source in $PROJECT
HOME/spring/resources.xml (where $PROJECT_HOME is the root directory of your Grails application).

projects> cat racetrack/spring/resources.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="dataSource"
        class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="jndiName" value="
java:jdbc/racetrack"/>
    </bean>
</beans>

Then, just run grails war to create the WAR, and that’s it.  Now, when you deploy the WAR to your app server, your Grails application will use your container-managed data source for all of its database access.

So, what other types of JEE integration would you look for in your Grails apps?  (Sound off in the comments, and perhaps we’ll have additional posts on this topic.)  If you found this particular example to be a bit trivial, great!  That’s exactly the point.  JEE integration doesn’t have to be painful, at least not with Grails.  

Resources 

  • JBoss configuration file for MySQL data source - mysql-ds.xml
  • Spring configuration file - resources.xml
  • The rest of this mysterious racetrack sample application - Coming soon!

Print This Post Print This Post

2 Responses to “Out of the Box Grails + JEE Integration”

  1. Achim Says:

    Well, that is certainly a nice feature. However once you put a dataSource bean in your resources.xml, the Grails data sources in grails-app/conf will no longer be used even if you do not deploy to a J2EE server. This means you can no longer use the jetty container that ships with Grails and all developers will have to have a J2EE container installed for deploying the application.

    Or alternatively, you have to replace the resources.xml file manually when you create a production deployment. It would have been nice to be able to, e.g., say “for environment dev, use DevelopmentDataSource, for test, use the datasource jdbc/GrailsTest from your app server, and for prod, use jdbc/GrailsProd” - or other constellations depending on your environment.

    Achim

  2. Jason Rudolph Says:

    Hi Achim, Yes indeed. That’s a legitimate gripe. Luckily Grails should support environment-specific resources.xml files likely before the 1.0 release.

    It looks like Graeme clarified this on the mailing list as well.

    Cheers, Jason