This week I’m in New Haven, CT, teaching a class that combines UML and Java Web Services (an odd combination to be sure).  The client wanted to use NetBeans as their primary IDE, and I always try to accommodate that if I can.

My last exposure to NetBeans was back in version 5.5, I think, when a couple of friends suggested I give it a whirl.  I’ve been an Eclipse user since version 1, so I’m very comfortable with that environment.  As part of giving a presentation at my local Java User’s Group, I also got a license for IntelliJ’s IDEA, so I’ve been playing with that off an on.  When I don’t want to use a heavy IDE, I generally stick with UltraEdit, which does a decent job, even with Groovy code.

Nevertheless, I downloaded and installed NetBeans 6.1.  I have to say that I’ve been very pleasantly surprised by the editor.  The UML support is surprisingly good, including the capability to generate sequency diagrams from code.  But its JAX-WS and JAXB support has been outstanding.  I’ve been using them with the embedded Glassfish server and really enjoyed it.

I’m in a bit of a rush (have to get back to class) or I’d say more.  What I can say, though, is that if the NetBeans group really does deliver on Groovy and Grails support in NB 6.5, as promised, I’m definitely going to try it.  I’m still mostly an Eclipse person (and the commercial MyEclipse tool as well).  I know it’s practically heresey to say so these days, but I’m still finding that IntelliJ slows me down a lot more than it speeds me up.  But this single week with NetBeans has been a revelation.  I can only hope the Groovy and Grails support when it comes out in October is as good as the rest of the IDE.

So I’m teaching my course in Securing Java Web Applications (my third one in the last six weeks) and we got to a section that discussed the MD5 algorithm for generating message digests.

One of the students asked, “whatever happened to MD’s 1 through 4?”

I simply couldn’t resist saying, “MD’s 1, 2, and 3 were sabotaged during construction.  MD4 vanished without a trace shortly after it came online.  Now we have MD5, our last, best hope for peaceful digests.”

To my pleasant surprise, about five different students got the joke.

(And yes, every time I see the abbreviation JMS I don’t think Java Message Service, I think J. Michael Straczynski.)

We live for the One; we die for the One.

As Tim Kurkjian famously said, “Never miss the opportunity to go to a baseball game.  You might see something you’ve never seen before.”

This week I’m in Asheville, NC.  I’m very busy with my Securing Java Web Applications class while other issues keep coming up, but the bottom line is that the Asheville Tourists (the class A affiliate of the Colorado Rockies) are nearby and are in town.  I was debating whether to go or not when I spoke to my wife on the phone.  As usual, she encouraged me to go.  She’s claims I’m always in a better mood after I’ve attended a ball game, so who can blame her?

Even better, minor league baseball team names in North Carolina are great.  I really liked the Lehigh Valley Iron Pigs when I was in Allentown a couple weeks ago, but NC has great names in abundance.  You’ve got the Greensboro Grasshoppers, the Winston-Salem Warthogs, the Kannapolis Intimidators, the Carolina Mudcats, and even tonight’s opponent, the Hickory Crawdads.  That doesn’t even mention the classic Durham Bulls.  But honestly, how can you not go to a game between the Tourists (who have had that name since 1914!) and the Crawdads?  It’s just not possible.

So I did my usual practice, which is to show up at the box office about a half hour before game time, told them I needed only one ticket and asked for the best available seat in the house.  In Asheville, that turned out to be a special “Home Deck Suite” right behind the on-deck circle (probability of a foul ball: zero), which cost a fortune ($45, an insane amount for a minor league game) but included all you can eat on the menu, delivered for seven innings by a helpful staff person.

That’s right — all you can eat.  The guy kept coming back asking if I wanted more, and I kept doing massive rationalizations justifying horrible overeating in order to consume enough to make the ticket worthwhile.  Let’s say that I think I managed to do so (er, hot dogs, popcorn, cheese nachos, a giant pretzel, and an endless supply of sodas, but I showed some restraint — no crackerjacks, though I was tempted), which I’m already regretting and surely will regret more tomorrow.  I even got lucky and sat next to a charming couple who were in town on business and had tons of minor league baseball stories to tell.  The guy next to me also reminded me that the manager of the Tourists is good old Joe Mikulik, the immortal star of this classic YouTube video featuring a managerial meltdown that is topped only by this one by Phil Wellman, and I saw Earl Weaver in his prime.

As for the game, the Crawdads won 7 - 1, but I definitely saw some things I’d never seen before:

• Hickory’s Bobby Spain went 4 for 5 with a home run, but he was outdone by his teammate Andrew Walker, who went 4 for 5 with two home runs.  They even went back-to-back in the top of the 2nd inning.  Is it too obscure a reference to think their slogan should be Walker and Spain and Pray for Rain?
• Hickory’s Harrison Bishop and Tom Boleska combined to strike out six batters in a row from the bottom of the sixth to the bottom of the eighth.  I was surprised when they took out Bishop after striking out four in a row, but then Boleska came in and struck out two more before the next guy grounded out weakly to second.
• The two teams combined for a total of seven (!) errors (Hickory made 4 and still won), which is more than I’ve seen in some Little League games.
• The catcher’s name on the Crawdads is Lars Davis.  Yes, he’s the catcher.  Don’t they therefore, by law, HAVE to call him Crash?
• The guy who sang the National Anthem was an excellent operatic singer.  Every anthem singer in Connecticut thinks they have to sing with a country twang or like they have vocal diarrhea (see Aguilera, Christina, or lament the sad, pathetic American Idolization of singing), but here I am in North Carolina and I get a trained voice with a fine instrument.  Go figure.

The weather was great, the crowd was small (2872) but enthusiastic.  Asheville is the champion of the first half of the season of the Northern Division of the South Atlantic league (an odd but interesting achievement), so on the way out they were giving away general admission tickets to any future game.

That means I have a free ticket to the game tomorrow, even if it’s not for a very good seat and I still have work to do.  Still, you should never miss going to a ballgame…

I’ve been traveling a lot lately.  Fortunately, this is baseball season, so sometimes I get a chance to visit a park I’ve never been to before.

Last week I was in Allentown, PA.  Actually, that’s not quite true — I was actually in Schnecksville, PA, a small suburb of Allentown.  It turns out that this year Allentown has a new baseball team.  The Lehigh Valley Iron Pigs are playing their inaugural season as the AAA affiliate of the Philadelphia Phillies.

(Two years ago, as part of an extended weekend road trip, my son Xander and I did the Phillies circuit.  We got tickets to see the Phillies at Citizens Bank park (a huge improvement over the old Veteran’s Stadium, but, then again, almost anything would be), then we saw the Reading Phillies (their AA affiliate), and finally swung around to see the Scranton/Wilkes-Barre Red Barons, who at the time were the Phillies AAA team.  Now that Scranton is the AAA team for the Yankees, we won’t be going back any time soon (I’d link to their web site, but hey, if you’re a Yankee fan, go find it yourself).  As a final aside, we were hoping to do a similar circuit for the Red Sox (Red Sox at Fenway, Portland Sea Dogs, Lowell Spinners), but couldn’t get tickets to any of them.  That’s right — the Single A Lowell Spinners were sold out, too.  Baseball is king in New England.)

I was teaching a private class last week, and the client was a major sponsor of the Iron Pigs.  That meant I was able to join a group of people in a good balcony section of Coca-Cola Park (an awful name, but there it is).  The whole pig theme was obvious, from the kids hanging out on the freshly mowed lawn in left-center, which was called Pigs on a Blanket, to the Pig Pen in right-center field.  Their program was even called Pork Illustrated.

We had a lot of fun, even though the Iron Pigs lost 5-4.  Still, the park was charming, we had excellent weather, and the people were friendly.  (Mostly — I did have an extended baseball discussion with a long suffering Cleveland Indians fan who hates all things Boston, which is probably understandable under the circumstances. ;))

This week I’m in Austin, TX.  Last night I drove out to Round Rock and got to see the Round Rock Express, the AA affiliate of the Houston Astros.  Yesterday the temperature peaked at 102, but there was a warm breeze and it cooled off a bit as the sun went down.  The stadium wasn’t terribly full, but the people who were there were quite enthusiastic.  The Express even won 3-0 and hit two home runs.  Other than taking forever to find my rental car in the parking lot (a sign of traveling too much is that you forget what your rental car looks like), I had a great time.

I’ve now added baseball caps from the Iron Pigs and the Express to my collection.  I used to get T-shirts everywhere for my son Xander, but he told me he doesn’t want them any more.  Now that he’s 16, all he wears are T-shirts with various rock bands on them.  So be it.  Be sure, though, to check out his band’s excellent studio recording of their song “Don’t Tell Me” at their MySpace page.

Next week I’ll be in Asheville, NC, and it looks like the Asheville Tourists (the class A affiliate of the Colorado Rockies) will be in town.  Maybe I’ll be able to buy another hat.

On May 31, 2000, I officially left my job at United Technologies and became a full-time technical trainer. It’s now been eight years since that day. While I don’t like to talk about personal things here very often, I thought that was worth a mention. That, and the fact that in all the training classes I’ve taught since then (probably somewhere around 250, though that might be a bit low), I’ve never missed a day.

As Inigo Montoya said, “Let me ’splain — no, it is too much. Let me sum up.” After receiving my Ph.D. in Aerospace Engineering from Princeton, I took a job as a research scientist at United Technologies Research Center in East Hartford, CT. I spent nearly 12 years there, mostly investigating the aerodynamics and aeroacoustics of jet engines. That meant lots of math (pretty cool) and lots of Fortran (shudder). Toward the end of my stay, I learned Java and switched to a different group at UTRC that specialized in Artificial Intelligence. Quickly realizing that twelve years of programming in Fortran hadn’t taught me anything about modern software development, I went back to school at night and got my MS in Computer Science from Rensselaer at Hartford.

Just before graduation I reentered the job market. This was in the Spring of 2000, just before the dot-com bubble burst completely. In the end, I had to choose between a developer job, and a job teaching training courses. One night at dinner with the family I said, “I’ve decided which job I want.” My son Xander, who had just turned 8 years old, said, “did you take the one with more money, or the one you liked?” I was very happy to say I took the one I liked, and became a member of the Golden Consulting Group.

Five years later, in March of 2005, I formed Kousen IT, Inc., and went out on my own. I now look back and can honestly say that I’ve never been happier. I spent years in jobs and in situations I intensely disliked. It took me a long time to correct all that. Now I’m finally in a job where

As for never missing a day of class, I simply can’t. These aren’t like academic classes, where you see a single group of students for months at a time (though, come to think of it, I’ve never missed a day teaching an academic class, either :)). People clear their work schedule for training classes. The classes only last three to five days, too, so missing a day is a huge sacrifice. No, I can’t miss a day if it’s physically possible to be there. It’s more than a responsibility; it’s an obligation.

I freely admit, though, that keeping a perfect record going involves some luck. I’ve certainly been sick enough to miss days. Earlier this year I caught some stupid stomach bug that knocked me for a major loop. I couldn’t get out of bed, much less make it to class. I’m just glad it happened to hit me on a day I wasn’t scheduled to teach.

I’m sure that first missed day is coming. Life simply isn’t always controllable like that. Illnesses happen, and I received a reminder about a week ago that my parents are aging and no longer in the best of health. As they say, stuff (or even life) happens.

Still, I wanted to take a moment to feel quietly pleased about the fact that I’ve made it this far.

Recent classes:

• EJB3 in Hampton, VA
• Securing Java Web Applications in Allentown, PA
• Grails presentation at my local Java user’s group
• My regular graduate class in Developing Enterprise Applications at Rensselaer

Upcoming classes:

• OOAD/UML in Austin, TX
• Java Web Security in Asheville, NC
• Java Web Services in New Haven, CT
• Java Web Security in Huntington Beach, CA

I was writing a very simple Grails application and ran into a problem when I accidentally used a SQL keyword as a property name. This post documents what happened, and how I (pretty easily) fixed it.

To illustrate the issue, consider a trivial Grails application called “messaging” with a single class called Message.

class Message {
  String from
  String to
  String text
}

This is supposed to represent a simple email message, with fields to represent the sender, the receiver, and the text of the message itself. It seemed quite logical at the time to use the words from, to, and text for the fields, but that leads to problems.

I added a MessageController with dynamic scaffolding (i.e., def scaffold = Message) and started the server. When I accessed the MessageController link, however, I got

org.hibernate.exception.SQLGrammarException: could not execute query

In order to see the actual problem, I modified my DataSource.groovy file to add “loggingSql = true” in the dataSource section. After restarting the server, in the console window I saw that the exception was caused by a SQL command generated by the scaffolded list method in MessageController:

Hibernate:
    select
        this_.id as id0_0_,
        this_.version as version0_0_,
        this_.from as from0_0_,
        this_.text as text0_0_,
        this_.to as to0_0_
    from
        message this_ limit ?

This statement looks fine, and in fact there’s nothing wrong with it. I couldn’t see the problem until I switched to MySQL so that I could browse the database independently.

(Switching to another database is covered many places in the Grails literature. In short, it means adding the JDBC driver to the messaging/lib directory, creating the messaging database in MySQL, and changing the driverClassName, url, username, and password settings in DataSource.groovy.)

When I did that and checked the database with the MySQL client, I found the problem (or at least a symptom of it):

mysql> show tables;
Empty set (0.00 sec)

In other words, the problem was that the message table didn’t exist. Somehow the SQL used to generate the table in the first place didn’t work.

Logging the SQL as I did wasn’t sufficient to show me the CREATE TABLE statement. If, however, I go into Config.groovy and change the value of log4j.logger.org.hibernate to debug, I see in the resulting console:

[1125] hbm2ddl.SchemaExport
    create table message (
        id bigint not null auto_increment,
        version bigint not null,
        from varchar(255) not null,
        text varchar(255) not null,
        to varchar(255) not null,
        primary key (id)
    )

followed immediately by

[1125] hbm2ddl.SchemaExport Unsuccessful: create table message …
[1125] hbm2ddl.SchemaExport You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘from varchar(255) not null, text varchar(255) not null, to varchar(255) not null’ at line 1


The problem is that the word “from” is a SQL keyword. MySQL got upset when I tried to use it in the create table statement, as shown above.

How can I fix this? I could change the name of the from property, to, say, sender. Since Grails 1.0, however, GORM now has the ability to do custom ORM mappings, which feels like a cleaner way to solve the problem. Therefore, I added the following closure to my class:

static mapping = {
  from column: 'sender'
}

Now the generated create statement is:

[1157] hbm2ddl.SchemaExport
    create table message (
        id bigint not null auto_increment,
        version bigint not null,
        sender varchar(255) not null,
        text varchar(255) not null,
        to varchar(255) not null,
        primary key (id)
    )

and the new error is

[1157] hbm2ddl.SchemaExport You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘to varchar(255) not null, primary key (id))’ at line 1

So apparently the word “to” is also a problem. I therefore modified the mapping closure to include it as well:

static mapping = {
  from column: 'sender'
  to column: 'receiver'
}

Now it all works as it should. The lesson appears to be either that I should keep a list of SQL keywords handy, or simply that the custom ORM DSL is a Good Thing(TM), and so are the logging settings.

This post discusses a relatively simple topic in GORM: how to use dependent variables in a domain class. It’s simple in the sense that it’s been discussed on the mailing list, but I haven’t seen it documented anywhere so I thought I’d do so here.

I started with a simple two-class domain model that I discussed in my last GORM post.

class Quest {
    String name
    static hasMany = [tasks:Task]
    String toString() { name }
}

class Task {
    String name
    static belongsTo = [quest:Quest]
    String toString() { name }
}

As before, there is a one-to-many relationship between quests and tasks. A quest has many tasks, and the belongsTo setting implies a cascade-all relationship, so inserting, updating, or deleting a quest does the same for all of its associated tasks.

In Bootstrap.groovy, I also have:

def init = { servletContext ->
         new Quest(name:'Seek the grail')
            .addToTasks(name:'Join King Arthur')
            .addToTasks(name:'Defeat Knights Who Say Ni')
            .addToTasks(name:'Fight Killer Rabbit')
            .save()
}

which shows how the classes are intended to work together.

The first change I want to make is to give tasks a start date and end date. My first attempt is to just add properties with those names, of type java.util.Date.

class Task {
  String name
  Date start
  Date end
  // ... rest as before ...
}

This leads to a minor problem. If I start up the server, I don’t see any quests or tasks. The reason is that my bootstrap code tries to create tasks without start and end dates, which violates the database schema restriction. My generated schema marks both start and end columns as “not null”.

There are many ways to fix that. I can either assign both start and end properties for each task in my bootstrap code, or add a constraint in Task that both can be nullable, or do what I did here, which is to give them default values.

class Task {
  String name
  Date start = new Date()
  Date end = new Date() + 1
  // ... rest as before ...
}

I do have a constraint in mind, actually. I’d like to ensure that the end date is after the start date. That requires a custom validator, which is also pretty easy to implement:

class Task {
  // ...
  static constraints = {
    name(blank:false)
    start()
    end(validator: {  value, task ->
       value >= task.start
    })
  }
}

That works fine.

Now for the dependent variable. My tasks all have a start and an end, so implicitly they have a duration. I could add the duration variable to my Task class, but I don’t want to save it in the database. It’s dependent on the values of start and end. I also don’t want to be able to set it from the gui.

Here’s the result:

class Task {
  String name
  Date start
  Date end

  int getDuration() { (start..end).size() }
  void setDuration(int value) {}

  static transients = ['duration']

  // ... rest as before ...
}

This computes the duration from the start and end dates by returning the number of days between them. It relies on the fact that Groovy modifies java.util.Date to have the methods next() and previous(), and since Date implements Comparable, it can then be used in a range, as shown.

(As an aside, this implementation is probably pretty inefficient. If the number of days between start and end was substantial, I think this implementation executes the next() method over and over until it reaches the end. I thought about trying to subtract the two dates, but interestingly enough the Date class only has plus() and minus() methods that take int values, not other Dates. I considered adding a category that implemented those methods, but haven’t tried it yet. I’d like to look in the Groovy source code for the plus() and minus() implementations, but I couldn’t find it. I did find something similar in org.codehaus.groovy.runtime.DefaultGroovyMethods, but I’m not sure that’s the same thing. Sigh. Still a lot to learn…)

By putting 'duration' in the transients closure, I ensure that it isn’t saved in the database.

The getDuration method is pretty intuitive, but adding set method as a no-op is somewhat annoying. If I leave it out, then Groovy will generate a setter that can modify the duration. As an alternative, according to GinA I can also supply my own backing field and mark it as final:

class Task {
  // ...
  final int duration

  int getDuration() { (start..end).size() }
  // ...
}

Just to be sure, I added the following test to my TaskTests:

void testSetDuration() {
    Task t = new Task(name:'Join King Arthur')
    shouldFail(ReadOnlyPropertyException) {
        t.duration = 10
    }
   q.addToTasks(t).save()
}

That passed without a problem.

Interestingly, the dynamic scaffold still generates a modifiable input text field for duration, both in the create and edit views. I can put my own value in it and submit the form without a problem. The result does not get saved, which is correct, but I don’t see an exception thrown anywhere in the console. If I generate the static scaffolding, I know that in Task.save there is a line like

t.properties = params

which is how the form parameters are transfered to the object. Presumably the internal logic knows enough to avoid trying to invoke a setter on a final field. Of course, as soon as I generate the static scaffolding, I usually just delete that row in the GSP form.

There’s one final (no pun intended) issue with the dynamic scaffolding. The generated list view puts its properties in <g:sortableColumn> tags. This holds true for the duration, as well. Normally, when I click on the column header, the result is sorted, ascending or descending, by that property. If I click on the duration column header, however, I get an “org.hibernate.QueryException: could not resolve property: duration of: Task“.

It turns out that the User Guide has a “Show Source” link for every tag. When I clicked on that link for the sortableColumn tag, I saw near the top:

if(!attrs.property)
  throwTagError("Tag [sortableColumn] is missing required attribute [property]")

The error I got in the console is “could not resolve property”, but it’s possible this is the source of that issue. I’m not sure. The only other source (again, no pun intended) of the problem I could see was the execution of the list action at the bottom. That would imply that Grails is generating the Hibernate query and we’re failing at that point, which would be consistent with the error reported above.

At any rate, the duration property now works in the domain class. I can always modify the views to ensure I don’t try to set it.

In GORM, when one class has a hasMany relationship with another, a java.util.Set is injected into the class. Sometimes, though, I want to use a List instead in order to maintain ordering. The Grails reference documents (see section 5.2.4 specifically) discuss how to do that, but there are other issues that I needed to solve in order to make this work.

Consider an application that demonstrates the issue involved. It has only two domain classes, Quest and Task. A Quest consists of many Tasks.

class Quest {
    String name

    static hasMany = [tasks:Task]

    String toString() { name }
}

class Task {
    String name

    static belongsTo = [quest:Quest]

    String toString() { name }
}

I’m using a bi-directional one-to-many association here, mostly because the dynamic scaffolding works well with it (not the best reason, of course, but it makes it easy to illustrate the point). The hasMany assignment means that the Quest class will have a Set injected into it called tasks, and the belongsTo relationship means that all the cascade relationships (save, update, and delete) will work, too.

Before I take advantage of that in my boostrap code, though, I used the dynamic scaffolding just to make sure I could add quests and tasks through the normal views.

class QuestController { def scaffold = Quest }

class TaskController { def scaffold = Task }

As it happens, everything does work as advertised. A simple integration test that demonstrates it is shown below, which works.

void testAddTasks() {
    Quest q = new Quest(name:'Seek the grail')
    q.addToTasks(name:'Join King Arthur')
        .addToTasks(name:'Defeat Knights Who Say Ni')
        .addToTasks(name:'Fight Killer Rabbit')
        .save()
    assertEquals 3, Task.count()
}

Everything so far is standard stuff. One of the defining characteristics of a Set, however, is that it does not support ordering. If I want ordering, there’s a chrysalis stage I can go through on the way to a List, which is to use a SortedSet (assuming Task implements the Comparable interface).

class Quest {
    String name
    SortedSet tasks

    static hasMany = [tasks:Task]

    String toString() { name }
}

class Task implements Comparable {
    String name

    static belongsTo = [quest:Quest]

    String toString() { name }

    int compareTo(Object o) {
        return name.compareTo(o.name)
    }
}

The dynamic scaffolding still works, too. I can add a task, as long as there is a quest available to add it to. The tasks are sorted by name, as they should be. I added the above quest and tasks to my bootstrap code, too, so they were available as soon as my server started.

Incidentally, there’s a down side to using a SortedSet that I hadn’t realized right away. When I first wrote my application, I added a degree of difficulty to my tasks and tried sorting by them.

class Task implements Comparable {
    String name
    Integer difficulty

    // ...

    int compareTo(Object o) {
        return difficulty - o.difficulty
    }
}

That sorts tasks by difficulty all right, but there’s another consequence. I can only add a single task of a given difficulty to a particular quest! I can’t have two tasks both with the same difficulty. A SortedSet may be sorted, but it’s still a set.

So now I move on to using a List. As the reference documentation says, to do that, just declare tasks to be a reference of type List.

class Quest {
    String name
    List tasks

    // ...

    static hasMany = [tasks:Task]
}

Now there’s trouble. The server starts, and the bootstrap code works, because it adds tasks to an existing quest before saving them. The dynamic scaffolding has a serious problem, though. When I go to the tasks list and try to add a new task, everything is fine until I try to save the new task.

If I try to add a new task through the “Create Task” page, I get an exception: “org.hibernate.PropertyValueException: not-null property references a null or transient value“.

The reason is addressed in the reference documentation. First, changing to a list means that the database table for tasks now has an index column. Second, as the documentation says, you can’t save a task by itself any more — you have to add it to a quest first. It’s okay to say:

def t = new Task(’Answer the bridgekeeper’)

but I can’t save it by itself, or that index column will be a problem. I have to add the task to a quest first before saving.

Quest.get(1).addToTasks(t).save()

That works. Otherwise I get a null in that index column, which throws an exception and down goes the server.

So, knowing that, how do I fix the system?

Well, I definitely have to abandon the dynamic scaffolding. The built-in save method isn’t going to work, because it saves the task independently of the quest. So, it’s time to generate the real controllers.

After generating the task controller and views, the save method looks like:

def save = {
    def task = new Task(params)
    if(!task.hasErrors() && task.save()) {
        flash.message = "Task ${task.id} created"
        redirect(action:show,id:task.id)
    }
    else {
        render(view:'create',model:[task:task])
    }
}

I need to add the task to a quest and then save the quest. Fortunately, one of the parameters in the request is the id of the quest, under params.quest.id. That means my first try is to change the above code to this:

def save = {
    def task = new Task(params)
    def q = Quest.get(params.quest.id)
    q.addToTasks(task)
    if (!task.hasErrors() && q.save()) {
        // ... etc ...
}

Unfortunately, this doesn’t work either. When I fill in the page to make a new task and try to save it, I get a NullPointerException due to the fact that the task still has a null id.

This, I believe, turns out to be a Hibernate problem. Hibernate doesn’t do the save when I ask it to, but rather is waiting until the “right moment” to do the commit. Unfortunately, I need that commit right away.

Fortunately, there’s an answer to that, too. The save method takes a flush parameter which can be set to true.

Therefore, I changed the above code to:

def save = {
    def task = new Task(params)
    def q = Quest.get(params.quest.id)
    q.addToTasks(task)
    if (!task.hasErrors() && q.save(flush:true)) {
        // ... etc ...
}

Now, at long last, it all works. The key was to add the task to the quest and save the quest with flush set to true.

It’s possible that there are alternative solutions, but this one worked for me. If you know of better alternatives, please let me know.

It’s probably not great for my reputation to show how I made a very silly error, but since I did it so consistently I thought showing it might help somebody avoid it.

My Groovy course materials consist of far more scripts than classes. That’s probably not surprising, given that teaching Groovy involves writing lots and lots of quick-and-dirty examples. The problem with scripts, though, is that they’re not as easy to test as classes. With classes, I can create a class that extends GroovyTestCase, put in my tests and go. With scripts, though, the same process would require either executing the script from a Groovy class and checking the binding properties, or simply using assert statements.

In general, I chose the latter. In my scripts, I tried to complete each with at least one assert call that I could use later to validate the script.

Sounds like a reasonable approach, right? Sure, until you start going too quickly. What’s wrong with the following code?

// inject demo
def strings = ["Hello","World"]
int totalLength = strings.inject(0) { len, s ->
    len += s.size()
}
assert 10, totalLength

The code is intended to be a trivial illustration of the inject method for lists. The result is supposed to be the sum total of the lengths of all the strings in the list. Ignoring that there are many other ways to solve that problem, the difficulty here isn’t the inefficiency of the algorithm. No, it’s a trap that as a long-time Java developer I found very easy to fall into.

The problem is with my assert statement. The intention is to assert that the total length of the strings in the list is 10. Sure enough, executing this code has no errors. That’s not a big surprise (for me), because at first I started with a println statement to see what the value should be, and then I replaced println with an assertion.

Unfortunately, though, my assertion didn’t prove anything about the script. That becomes obvious if I add another line to the program:

assert 50000, totalLength

which passes just as easily.

What’s wrong? I’m using assert as though it was a two-parameter method, like assertEquals in GroovyTestCase.

What I’m trying to do is to specify the right answer followed by the actual test. What I’m actually doing is asserting that the first argument (a literal number) is true, and supplying an error message to print if not. By the Groovy truth, any non-zero number is always true, so my totalLength never needs to be converted to a string and printed as the the error message.

What I really want to use, of course, is

assert 10 == total, “total should be 10″

I think this is an easy trap for Java developers to fall into, because they’re not accustomed to the Groovy truth. In Java, only a real boolean expression can be true or false, not just a number.

What’s truly embarrassing is how many of my scripts were just asserting that a non-zero value was true, which always works.

Once I realized my mistake (because somebody pointed out one of my bad examples), I had to go back and fix all of my tests. They’re better now.

This isn’t really a problem, but I don’t think it’s documented anywhere, so I thought I’d record it here.

(And by the way, if your reaction to my Windows-based comments is going to be “why not use something other than Windows,” my answer is (1) at least one of my machines is always running Windows, but more importantly (2) my clients overwhelmingly use Windows in their training rooms, so I can’t get away from it even if I wanted to.)

Like Groovy, the Grails downloads page includes a special installer for Windows. You don’t have to use it — it’s still fine to just download the zip file, unpack it, set the GRAILS_HOME variable and go on, but if you do decide to use the Windows installer you should know that a few details have changed.

First of all, when the installer runs, it creates a different directory structure than that found in the regular zip file. The installer creates a structure like:

c:\grails-1.0.2\
bin\
gbin\
grails\
… other files ..

which means the GRAILS_HOME variable needs to point to “c:\grails-1.0.2\grails” rather than “c:\grails-1.0.2″ as the User Guide says. That also means that if you want to put Grails in your path for all command prompts, you need the “bin” directory under “grails”, not the one under “grails-1.0.2″. Personally, I assigned GRAILS_HOME to “c:\grails-1.0.2\grails” and put “%GRAILS_HOME%\bin” in my path, just be sure.

This also comes up if you’re using the JetGroovy plug-in for IntelliJ IDEA. The plug-in requires you to specify where the root of the Grails distribution is, which again is the “grails” subdirectory.

In principle, a lot of this isn’t even necessary. The installer creates a desktop shortcut called “Grails Environment” which is a configured command prompt. When I fire it up on my machine and check the path, I see that the directories

c:\jdk1.6.0\bin
C:\GRAILS~1.2\grails\ant\bin
C:\GRAILS~1.2\grails\bin
C:\GRAILS~1.2\GRAILS\..\gbin

have all been prepended (i.e., they appear at the beginning, rather than the end) to my path. The first one is very likely just my “%JAVA_HOME%\bin”, which was already in there, but again that’s not really a problem.

The other interesting characteristic about the “Grails Environment” window is that inside it, you don’t need to type the word “grails” in front of each command. You can just type “create-domain-class myclass” or whatever, and it works automatically. The Grails command line interface is already running.

For the create-* commands to work correctly, of course, you need to be in the root of your Grails application. The environment prompt looks like this:

[C:\grails-1.0.2]
grails:\>

at it starts, which is in the root of the Grails distribution. I needed to change directories to my own application, so after a couple of “cd”s I wound up with

[C:\grails_apps\myapp]
grails:\>

The environment supports all the normal DOS commands, like “dir” or “cd”.

Incidentally, there’s no problem firing up more than one instance of the “Grails Environment”. It creates a separate command window for each case.

There has also been a change to the documentation. In earlier versions, the User Guide (an excellent resource, getting better all the time) was stored in HTML form, and was basically a copy of the documentation found here. Now, using the installer, the documentation has been bundled inside a Windows help file, which has the file extension *.chm.

Finally, the installer adds entries under “Start->All Programs->Grails 1.0.2″. Those entries are:

API Documentation (a link to the included JavaDocs for Grails)
Grails Environment (discussed above)
Grails References (a link to the Windows help file)
Grails Web site (a link to http:\\grails.org)
Uninstall Grails 1.0.2 (which does what it says)

As with most things in Grails, it’s very forgiving. You can use it, or not. If you prefer the older (or should I say, “classic”?) style, just download the zipped distribution and go from there. If you want the installer to do that extra work for you, that’s fine too. I think, though, that including a README file of some kind containing all this information might be helpful.

Still, I tend to like these sorts of installers. I spend more time running training classes than I do on my own systems doing development, so set-up is an ongoing challenge for me. I’m tempted to tell the person setting up a training room to just download and run the Windows installer and they’re done. I may do that for my upcoming Grails class, but I haven’t quite decided yet.

By the way, Groovy also comes with a Windows installer. I really like that one. It creates the same directory structure that the zip file contains, but it also offers to create a GROOVY_HOME variable and add its “bin” directory to either your path or the system path, installs a native environment (whatever that is, but it sounded good), and downloads and installs optional components like Scriptom and the Graphics environment. Using that one is a no-brainer for me, though I’ve found it to be a bit slow.

I hope this helps someone. The creator of the installer is Chanwit Kaewkasi, who is active on the Grails users list. He was kind enough to answer my questions about it there.