Working with Grails 1.0.1 inside Eclipse

I've started on a new project using Grails 1.0.1 and I've had to change a few things since working with Grails 1.0-RC4. Fortunately I did get an upgrade to Grails 1.0 into my application before deploy but 1.0.1 came too late to make it through our regression testing on that application. Today starts a new development project from scratch so I'm using 1.0.1 and when I went to use grails create-app it crashed on me... sorry I wish I had saved the trace... but I fixed this issue by deleting the ~/workspace/.metadata directory from my workspace.

Unfortunately, when you delete the .metadata directory Eclipse forgets many of your settings. In setting up my new eclipse project for Grails I set up the Eclipse Groovy plugin to output to bin and I set the build path of Java to output to project/bin which made both Groovy and Java compilers output to the same directory. This seems to work well with JPA classes too. After I get farther with this project I'll write up yet another Groovy, Grails, and the JPA tutorial using the new 1.0.1 conventions.

This next project will make heavy use of XML and XSD files as well so this should be a very informative project. Another problem to solve will be using SSL certificates and CAS. The CAS work has been very easy thanks to the CAS Client Plugin for Grails (it works great if you already have CAS set up). Now I need to add role management... but that's another story.

Groovy Grails and the JPA

If you are using Grails 0.6 or later chances are the tutorials you've found for making EJB3 persistence annotated POJOs work with Grails don't match up exactly. If you're like me, probably need to be made aware of a few differences in configuration. They aren't big... but the little differences could trip you up.

First note my version of myApp/grails-app/conf/DataSource.groovy

import org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsAnnotationConfiguration
dataSource {
    configClass = GrailsAnnotationConfiguration.class
    pooled = true
    dbCreate = "create-drop"
    driverClassName = "com.mysql.jdbc.Driver"
    dialect= org.hibernate.dialect.MySQLInnoDBDialect
    url = "jdbc:mysql://localhost:3306/grails"
    username = "grails"
    password = "grails"
}

Is not the same. Just because configClass = GrailsAnnotationConfiguration.class is set and your IDE says the class is found in this context doesn't mean that it's working for you... that import above still has to happen...

Next, I have added a file under "grails-app/conf/hibernate/hibernate.cfg.xml" and this part goes pretty much like the tutorials from last year... you register each class here one at a time. I need to research this one but I think grails mixes in this hibernate.cfg.xml with another one at run time so just stick to registering your classes. I tried to get fancy here and it didn't work out too well. My working hibernate.cfg.xml looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration SYSTEM
 "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
  <session-factory>
    <mapping package="com.mycompany.shared.domain" />
    <mapping class="com.mycompany.shared.domain.Subject" />
   </session-factory>
</hibernate-configuration>

You'll need your Java files to be in "src/java" and annotated up. I will be trying to make a shared JAR file full of only the shared domain objects for the various projects that need them. I don't know how well this is going to work but my idea is to create one set of JPA annotated EJB3 Entity classes and put them in a JAR and share them between various Spring applications. I don't know if that's a good idea or not...

Finally, you'll need to get the compiled class files for these annotated POJOs into "web-app/WEB-INF/classes" that means you need to do a "grails run-app" or similar first so that the Java files get compiled into classes and dropped into the "web-app/WEB-INF/classes" directory.

Once that is done you can run the "grails generate-all" command on your Java classes.

If you're interested in working through the EJB3 examples I have posted ejb3_grails.zip which uses this tutorial by Jason Rudolph but also uses Grails version 1.0_RC1 and the Groovy Eclipse Plugin.

EDIT: in version 1.0 and higher recent experience shows that if you set the Eclipse Groovy plugin to output to bin and set the build path of the Java compiler to output to project/bin class resolution will work fine for the IDE. When Grails itself goes to run the application or build the WAR file, the right class files will make it into "WEB-INF/classes" since Grails uses a separate class cache anyhow. It seems the reason I advised to output Groovy and Java classes to "web-app/WEB-INF/classes" is no longer true.

EJB3 security annotations

So with EJB3 declarative security annotations I can do things like this:

@DeclareRoles("ADMIN", "USER")
public class Frobnicator {
  @RolesAllowed("ADMIN","USER")
  public boolean checkFrobnication() { ... }
 
   @RolesAllowed("ADMIN")
  public boolean fullyFrobnicate() { ... }
}

Which will allow me to lift the Frobnicator bean out and drop it into a JUnit tests as a POJO. The POJO can then call the methods in Frobnicator without authentication. This helps doing unit tests and getting higher code coverage. But... isn't the authentication part of what I've written? Isn't that something that needs testing?

So my predicament is how do I provide automated acceptance testing for all the permutations of roles in the system?

Hibernate3 is not EJB3

My first and most painful lesson in my year with J5EE was about Hibernate, Hibernate3, annotations, and EJB3. I had been lead to believe by an evil leprechaun that EJB3 was just Hibernate. I learned by actual experience in creating applications that this is simply not true. In fact EJB3 is a standard that Hibernate3 implements.

Why is that an important distinction?

Because EJB3 features are a proper subset of Hibernate3 features since Hibernate "embraces and extends" the EJB3 standard. It also means that if you do intend on using those cute little "at" signs in a "portable" way you'll have to figure out what EJB3 annotation to use to solve the Hibernate trace you just saw.

EJB3 doesn't require XML sit-ups and the EJB3 implementation in JBoss that sits on top of the Hibernate3 layer hides those gut busting crunches from your beady little eyes. So using the EJB3 persistence feature is far less painful than using the Hibernate 2 XML workout routine. That would typically mean that you'd want to use the EJB3 model whenever possible.

The problem is that Annotations for persistence and XML for persistence can get into fistycuffs. If you set up a Hibernate SessionFactory (even if it's a version 3 session factory) you may use XML docs _or_ annotations... theory may say otherwise but when I sat down to mix my annotated classes with XML configured classes the programmatic changes to the configuration wouldn't stick.

Hibernate3 is not EJB3.

jBPM, EJB3 Persistence, Hibernate....

I think I'm going to go nuts. jBPM, EJB3 Persistence, and Hibernate... all playing nice-nice together? Is it possible? Apparently not.