Entries Tagged 'Grails' ↓

It turns out you can. It’s yet another poorly documented grails feature. You can just put -unit or -integration on the command line with test-app, like so:

grails test-app -unit

grails test-app -integration

Notice the space between test-app and the other bits. It’s important.

Have you ever seen a GSP error and wondered what the hell line number it was talking about? Well, if you’re running your grails app in development mode, throw a showSource=1 on the query string and it’ll show you the generated java code!

I came across an interesting problem with someone’s groovy code, and was able to reproduce the problem. In the interest of not having to bang my head against this again, I repeat the problem for you:

public class Parent
{
  def varName

  def gimmeVarName()
  {
    return varName
  }
}

public class Child extends Parent
{
  def varName = "Hello World"
}

public class Runner
{
  static void main(args)
  {
    def c = new Child()
    println c.gimmVarName()
  }
}

Now, what do you think happens here? I expected it to print out “Hello World.” I got a NullPointerException. Looking closer, however, the answer is fairly obvious. The “def varName” inside Parent defines a variable for itself, and the Child defines a new variable, with the same name, in the outer scope. I was able to fix this issue two ways. First, the bad way, by fixing Parent:

public class Parent
{
  def varName

  def gimmeVarName()
  {
    return getVarName()
  }
}

Now, by calling the auto-generated bean method, it starts at the scope of Child and finds it immediately — returning me a string. That must mean when I say return varName it’s not using the accessor function, but rather accessing the variable directly (which is, arguably, the correct thing to do).

Of course, the way to properly fix it is to use proper constructors to set those kinds of things up:

public class Child extends Parent
{
  Child()
  {
    varName = "Hello World"
  }
}

Then, the original function works fine. It seemed really weird at the time, but makes perfect sense now.

I’ve recently finished an internal taglib that allows us some awesome extended scaffolding. I may try to turn it into a full-fledged plugin/project, but for now, here’s a few tips for the ether:

First, to return errors from a taglib, you can simply call a function called “throwTagError”. I didn’t see that documented a lot of places.

Second, to see if a gsp template exists, you can do something like this inside a taglib:

def fullUri = grailsAttributes.getTemplateUri(template, request)
def resource = grailsAttributes.pagesTemplateEngine.getResourceForUri(fullUri)

if ( resource && resource.file && resource.exists() )
    // good template
else
    // bad template

Grails version: 1.0.3

I have about 150 domain classes that are defined in another project, and I’m importing them into grails. I put the hibernate config in conf/hibernate/* and all the classes and .hbm files there as well. Saving, updating, etc., work fine.

To add constraints to these classes, since I am not doing them in groovy, I just stick a file in src/java/[package]/[classname]Constraints.groovy. And those get picked up just fine as well.

Now comes the bad part: when it’s done this way, it doesn’t seem grails picks up the default messages in your grails-app/i18n/messages.properties file. I removed all the default.* from the file, and all the messages showed up fine and dandy. They shouldn’t have.

I tracked this down because the unique constraint threw an exception when trying to print the error message. The constraint checking takes place, but for some reason it can’t find default.not.unique.message in the file — even though it’s clearly there. It’s like it ignores all default.* messages when you’re not using groovy domains.

But, here’s the catch: if you define the constraint messages in the class.property.constraint method, they show up just fine. So clearly it’s READING and UNDERSTANDING the file. I just didn’t want to have to throw 1000 lines of messages in here for something I should be able to do with 3.

I’ve filed my first ever JIRA ticket for it. I get #3228. Yay me.

When you’re trying to build grails for a CI server (I’m using Hudson), it’s recommended that you don’t check certain things into subversion. To restore those things properly in the environment, you should run “grails upgrade.” The problem, of course, is that grails upgrade requires some interactive input asking if you’re willing to overwrite files.

Apparently, you can just go grails upgrade -force and it will do it without interactive input. So, your ant task looks like this:

    <!-- =================================
          target: upgrade
         ================================= -->
    <target name="upgrade" description="--> Runs grails upgrade to restore stuff after svn checkout">
        <exec executable="${grails}" failonerror="true">
            <arg value="upgrade -force" />
        </exec>
    </target>