Spring Tool Suite
  1. Spring Tool Suite
  2. STS-1636

Grails application with audit-trail plugin fails to run on tcServer

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.6.0.M2
    • Fix Version/s: None
    • Component/s: GRAILS, SERVER
    • Labels:
      None
    • Environment:

      Grails 1.3.6, Windows 7 64-bit, JDK 1.6.0_23

      Description

      When a project is created that uses certain Grails plugins that perform AST transformations, STS is unable to deploy these to the built in tcServer and have it successfully start. Much progress was made in 2.6.0.M1 but there appear to still be issues.

      To reproduce with a simple case I followed these steps:
      grails create-app BugReport
      install-plugin spring-security-core
      install-plugin audit-trail
      create-domain-class MyDomain
      Edit Config.groovy to add audit stamp config
      Edit MyDomain.groovy to add @gorm.AuditStamp annotation and a couple dummy properties
      Edit BootStrap.groovy to create some instances of the MyDomain class, then attempt to query them using a field added by the audit-trail plugin.

      1. bugReport.log
        15 kB
        Brandon Kane

        Activity

        Hide
        Kris De Volder (c) added a comment -

        I'm attaching my own sample project for future reference.

        Show
        Kris De Volder (c) added a comment - I'm attaching my own sample project for future reference.
        Hide
        Brandon Kane added a comment -

        The workaround was successful. Hopefully a proper fix can get implemented eventually, but for now this allows me to deploy to tcServer in STS, and most importantly, use Spring Insight.

        Thanks for the help Kris, I'll be happy to test out a dev build once it is available.

        Show
        Brandon Kane added a comment - The workaround was successful. Hopefully a proper fix can get implemented eventually, but for now this allows me to deploy to tcServer in STS, and most importantly, use Spring Insight. Thanks for the help Kris, I'll be happy to test out a dev build once it is available.
        Hide
        Kris De Volder (c) added a comment -

        Hi Brandon,

        I also would like to put in a fix... eventually... but... I'm a having a really hard time of thinking of a way this could actually be fixed. Starting up a new JVM to run the greclipse compiler just to set the user workdir to satisfy that transform is out of the question. That would be a major change and probably come with a major performance hit as well.

        Hacking around with setting "user.dir" system property might work, but it is very risky in the multi-threaded environment of Eclipse, where several compile things may be executing simultaneously on different projects.

        It may be that there isn't really a good way to fix this, unless the plugin itself is changed to work in a way that is more amenable to running in STS. I also thought about this a bit, but even that seems quite tricky. How would the ASTTransform in the plugin be able to access the config file it is after, if not by using a relative path of some sort?

        Tricky issue, so a fix may not be forthcoming for a while.

        The option to disable incremental deployment and deploy grails-builts war files "as is" will probably help. That seems within reach, but I won't be putting that into the next release yet. I played with it a bit and it was too unstable still to risk it.

        So... I'm glad you are okay with working the workaround for now.

        BTW: the flushing procedure described above may be simplified. It looks like just doing a "clean" of the project should flush both classes in the classloader and the .class files on disk.

        Kris

        Show
        Kris De Volder (c) added a comment - Hi Brandon, I also would like to put in a fix... eventually... but... I'm a having a really hard time of thinking of a way this could actually be fixed. Starting up a new JVM to run the greclipse compiler just to set the user workdir to satisfy that transform is out of the question. That would be a major change and probably come with a major performance hit as well. Hacking around with setting "user.dir" system property might work, but it is very risky in the multi-threaded environment of Eclipse, where several compile things may be executing simultaneously on different projects. It may be that there isn't really a good way to fix this, unless the plugin itself is changed to work in a way that is more amenable to running in STS. I also thought about this a bit, but even that seems quite tricky. How would the ASTTransform in the plugin be able to access the config file it is after, if not by using a relative path of some sort? Tricky issue, so a fix may not be forthcoming for a while. The option to disable incremental deployment and deploy grails-builts war files "as is" will probably help. That seems within reach, but I won't be putting that into the next release yet. I played with it a bit and it was too unstable still to risk it. So... I'm glad you are okay with working the workaround for now. BTW: the flushing procedure described above may be simplified. It looks like just doing a "clean" of the project should flush both classes in the classloader and the .class files on disk. Kris
        Hide
        Kris De Volder (c) added a comment -

        Lowering priority on this because there's a feasible workaround (and there's no easy way to fix this given the way the AST transform works).

        Show
        Kris De Volder (c) added a comment - Lowering priority on this because there's a feasible workaround (and there's no easy way to fix this given the way the AST transform works).
        Hide
        Kris De Volder (c) added a comment -

        I made the issue title more descriptive of the actual problem.

        Show
        Kris De Volder (c) added a comment - I made the issue title more descriptive of the actual problem.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Brandon Kane
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              First Response Date: