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

Un-checking the "Keep external Grails running" leads to the GGTS can't start no Grails commands and presents the grails prompt instead.

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.3.0.RELEASE
    • Fix Version/s: 3.4.0.M1
    • Component/s: GRAILS
    • Labels:
    • Environment:

      Windows (XP, 7, 8) (32 or 64 bit), Java 6 or 7, GGTS 3.3.0 and Eclipse 4.3

      Description

      I updated my 2.2.3 project to the 2.3M2. As soon as you make a clean and refresh of the dependencies, with the un-checked options every command from GGTS leads to the grails prompt presented. But the prompt can't be used to enter the commands, because this leads to error, that the build listener can't be load. This also happens with a newly created 2.3 project. Setting this setting back resolves the issue, but leads to many unneeded started Grails consoles . I even tested it with the latest nightly of IDE, Grails and Groovy, but all remains the same.

        Activity

        Hide
        Kris De Volder (c) added a comment - - edited

        There's some special Windows escape code in GGTS. It apparantly there to avoid a bug in Java ProcessBuilder API where it would inadvertently split arguments that were meant to stick together.
        The code essentially adds quotes around the command before sticking it in an argument to GrailsScriptRunner. It used to be that without these special handling ProcessBuilder on Windows would split the argument appart into multiple arguments.

        Right now as I'm debugging however I can see that without the quotes process builder seems to actually do the right thing. Adding quotes no longer seems necessary and in fact causes a problem as it now passes the quotes to Grails which also treats them as escape sequences to keep the argument in one piece.

        The bug in question is this one:
        http://bugs.sun.com/view_bug.do?bug_id=6468220

        I suspect now that the determining factor is the JVM version. I.e. need to determine what versions of JVM has the bug and only add the quoting as needed.

        Show
        Kris De Volder (c) added a comment - - edited There's some special Windows escape code in GGTS. It apparantly there to avoid a bug in Java ProcessBuilder API where it would inadvertently split arguments that were meant to stick together. The code essentially adds quotes around the command before sticking it in an argument to GrailsScriptRunner. It used to be that without these special handling ProcessBuilder on Windows would split the argument appart into multiple arguments. Right now as I'm debugging however I can see that without the quotes process builder seems to actually do the right thing. Adding quotes no longer seems necessary and in fact causes a problem as it now passes the quotes to Grails which also treats them as escape sequences to keep the argument in one piece. The bug in question is this one: http://bugs.sun.com/view_bug.do?bug_id=6468220 I suspect now that the determining factor is the JVM version. I.e. need to determine what versions of JVM has the bug and only add the quoting as needed.
        Hide
        Kris De Volder (c) added a comment -

        Quick update.

        I tried with different versions of JVM 1.7 and as far back as 1.6 u15. The behavior seems consistent.

        I can fix the problem by disabling the special 'escape' code for windows. But as it was put in for a good reason way back I'm a bit reluctant still to turn it off without understanding potential repercussions.

        I think the problem this escape code addressed was observed on Win XP. I will need to double check that removing the code doesn't create a problem for Win XP users (there may still be a few out there).

        Show
        Kris De Volder (c) added a comment - Quick update. I tried with different versions of JVM 1.7 and as far back as 1.6 u15. The behavior seems consistent. I can fix the problem by disabling the special 'escape' code for windows. But as it was put in for a good reason way back I'm a bit reluctant still to turn it off without understanding potential repercussions. I think the problem this escape code addressed was observed on Win XP. I will need to double check that removing the code doesn't create a problem for Win XP users (there may still be a few out there).
        Hide
        Kris De Volder (c) added a comment -

        Just tested on Win XP. Even on Win XP the special windows escaping code is not needed (and causes the bug when its there).

        So I still don't know why exactly this workaround for http://bugs.sun.com/view_bug.do?bug_id=6468220
        is no longer needed while it was at some time in the past.

        I have verified that the ProcessBuilder bug still exists even JVM7!

        With a breakpoint in ProcessBuilder I also found that the 'special quoting' are still being applied.
        So presumably Eclipse has its own workaround for he processbuilder bug (GGTS doesn't use ProcessBuilder directly but via Eclipse).

        If we are no longer exposed to this bug now but where in the past, maybe the workaround for the bug in Eclipse is only present
        in some versions of Eclipse. That seems to be the only explanation left.

        I'll need to check whether GGTS based on 4.2 and 3.8 are affected or not.

        Show
        Kris De Volder (c) added a comment - Just tested on Win XP. Even on Win XP the special windows escaping code is not needed (and causes the bug when its there). So I still don't know why exactly this workaround for http://bugs.sun.com/view_bug.do?bug_id=6468220 is no longer needed while it was at some time in the past. I have verified that the ProcessBuilder bug still exists even JVM7! With a breakpoint in ProcessBuilder I also found that the 'special quoting' are still being applied. So presumably Eclipse has its own workaround for he processbuilder bug (GGTS doesn't use ProcessBuilder directly but via Eclipse). If we are no longer exposed to this bug now but where in the past, maybe the workaround for the bug in Eclipse is only present in some versions of Eclipse. That seems to be the only explanation left. I'll need to check whether GGTS based on 4.2 and 3.8 are affected or not.
        Hide
        Kris De Volder (c) added a comment -

        Finally! Confirmation: this bug was fixed in Eclipse 4.3:

        That explains why lots of people are hitting the problem with GGTS 3.3.0 RELEASE. It's the first release that offers a 4.3 based build.

        It seems to properly close the GGTS bug here I need to deactivate my own ProcessBuilder bug workaround conditionally for Eclipse 4.3 but leave it active for 4.2, 3.8 (or older).

        Show
        Kris De Volder (c) added a comment - Finally! Confirmation: this bug was fixed in Eclipse 4.3: https://bugs.eclipse.org/bugs/show_bug.cgi?id=387504 That explains why lots of people are hitting the problem with GGTS 3.3.0 RELEASE. It's the first release that offers a 4.3 based build. It seems to properly close the GGTS bug here I need to deactivate my own ProcessBuilder bug workaround conditionally for Eclipse 4.3 but leave it active for 4.2, 3.8 (or older).
        Hide
        Kris De Volder (c) added a comment -

        A proper fix is now committed. Closing issue.

        Show
        Kris De Volder (c) added a comment - A proper fix is now committed. Closing issue.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Anton Pinsky
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: