Grails
  1. Grails
  2. GRAILS-8800

GroovyCastException thrown when casting null using Groovy "as" operator

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.0.2
    • Component/s: Commons
    • Labels:
      None
    • Environment:
      Java 1.6 b29, Grails 2.0.1, Mac OS X 10.7.3
    • Testcase included:
      yes

      Description

      When casing a null value (either directly, or the result of a calculation) using the Groovy "as" operator, a GroovyCastException is thrown.

      I had trouble reproducing this initially, and I don't yet know the root cause, but I have been able to get a reproducable project with minimal code changes. The attached project is just the result of:

      0. Using Grails 2.0.1
      1. Run grails create-app
      2. Remove dependency to the resources plugin
      3. Run grails create-controller
      4. Add a controller method with "1 as Long" as well as rendering some text (just so if it does succeed we see something)

      The behavior is quite odd when it does or does not occur (but is deterministic in a given situation)

      -Only occurs when WAR'd up, never in run-app.
      -Occurs when running as run-war, and deployed to a tomcat 6 or 7 instance
      -Occurs whenever there is a null cast using "as" to a type (e.g. null as Long)
      -Does not occur when doing regular casting (e.g. (Long)null), or when assigning a null value to a strongly-typed variable (e.g. Long x = null)

      Add to that list now with this attached project:
      -Occurs in a clean grails project if the dependency to the resources plugin is removed

        Activity

        Hide
        Michael Cameron added a comment -

        I've continued to narrow down the proximate causes. At this point it appears that something is changing Groovy's NullObject's MetaClass and adding in the new ConvertersApi. Then, the ConverterUtil.invokeOriginalAsTypeMethod does not handle nulls correctly, or more precisely, when the delegate is a NullObject then delegate != null, so it falls through to execute DefaultGroovyMethods.asType when instead there should be a check for delegate instanceof NullObject which calls NullObject.asType(clazz).

        The changes above should fix it, but I have not been able to find the source of the pollution. As stated previously, this is only happening when running a WARed version of the application, and for some reason the resource plugin changes the behavior. When trying to track down the where in the resource plugin this occurs I get really weird, but deterministic behavior. When commenting or uncommenting various lines to track down what changed it, I would have situations where commenting out log lines (with a GString with expansions) would change the behavior (again, deterministically). Also, when running without the resources plugin, I would attach a debugger to tomcat to try to catch what was creating a NullObject ExpandoMetaClass, but when the debugger was attached, that never happened, and when grails was done starting, the errant behavior did not occur. When not attaching the debugger during start-up, the behavior will occur.

        Show
        Michael Cameron added a comment - I've continued to narrow down the proximate causes. At this point it appears that something is changing Groovy's NullObject's MetaClass and adding in the new ConvertersApi . Then, the ConverterUtil.invokeOriginalAsTypeMethod does not handle nulls correctly, or more precisely, when the delegate is a NullObject then delegate != null , so it falls through to execute DefaultGroovyMethods.asType when instead there should be a check for delegate instanceof NullObject which calls NullObject.asType(clazz) . The changes above should fix it, but I have not been able to find the source of the pollution. As stated previously, this is only happening when running a WARed version of the application, and for some reason the resource plugin changes the behavior. When trying to track down the where in the resource plugin this occurs I get really weird, but deterministic behavior. When commenting or uncommenting various lines to track down what changed it, I would have situations where commenting out log lines (with a GString with expansions) would change the behavior (again, deterministically). Also, when running without the resources plugin, I would attach a debugger to tomcat to try to catch what was creating a NullObject ExpandoMetaClass, but when the debugger was attached, that never happened, and when grails was done starting, the errant behavior did not occur. When not attaching the debugger during start-up, the behavior will occur.

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Michael Cameron
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development