Announcement Announcement Module
Collapse
No announcement yet.
Strange: compiled outdated classes wrongly cached Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Strange: compiled outdated classes wrongly cached

    Under Ubuntu 12.04 64-bit + GGTS 3.4.0 + Grails 2.2.4 + Groovy 2.1.8 environment.

    I have a unit test class(CommonServiceTests.groovy) to test my service(CommonServie.groovy). Recently, when I changed some code in my servie, and used my test class to test it, my test class always used the old/outdated code of my servie. That is to say, new code doesn't get compiled automatically.

    I tried to use "grails clean" command to clean the target classes, then found they were all got deleted. But when I unit test the service code, the old code in my service was got tested. Where are they hiding? It's really strange.

    Any idea? please advise.
    Last edited by CK Chen; Feb 25th, 2014, 12:33 PM.

  • #2
    Update: When I restart GGTS 3.4.0 and run the test right away, the new service code will be called correctly. But, once I edit the service code later, I will be forced to restart GGTS again to get it called, otherwise, catched/outdated service code would be called.

    Comment


    • #3
      Are you running your test via a grails command (test-app) or via the Eclipse built-in Junit test runner (I.e. context menu >> Run As >> Junit test).

      It makes a difference because the former should use the compiled code as produced by grails. The other one uses code as compiled by the IDE.

      To force the ide to 'rebuild' all code in a project you should use the 'Project >> Clean' menu. To force grails to recompile probably running 'grails clean' command should do it.

      If something isn't getting recompiled when it should it could be some kind of a bug... but you'll have to be a bit more precise about what exactly you are doing so we can try to reproduce, diagnose and fix it. Also... so we can decide whether to blame the IDE or grails :-)

      Comment


      • #4
        Thanks Kris, your information is very valuable.

        Follow you suggestion, I figured out that the using catched/outdated class problem only appers when under using Grails test-app satuations. That is to say, the "context menu >> Run As >> Junit test" works correctly.

        For the ploblematic using Grails test-app satuations, I ran the same command "grails test-app unit:unit com.mydomain.myproject.CommonServiceTests" under:

        1) Under Grails perspective - click the "Grails Commond History" icon - input/select the above command from the pop-up window;
        2) From OS shell - grails> prompt - input the command directly;

        In either of the above satuation, only the old/catched/outdated CommonService class' code was called. I even tried Project - Clean... or grails> clean before the test, but no effect, unless I restart GGTS, it would work just for the FIRST test run.

        Anyway, the traditional "Run As ...Junit Test" approach you mentioned works fine for me, thanks again.

        Comment


        • #5
          So this is most likely a bug / problem in Grails rather than GGTS. Allthough in that case it is odd that the problem is fixed when you restart GGTS.
          That suggest maybe the problem comes from the grails process state. When GGTS runs commands it uses something similar to grails 'interactive' process.
          So when you run more than one command on the same project it will re-use the process. When you shutdown GGTS the process is also killed. So that might explain why it works next time.

          You could try disabling this feature. It is in the Grails Preferences Page under 'Launch' its called 'Keep External Grails Process Running'.
          Disable that checkbox and see if it makes a difference.

          If it does then likely the 'long running process' is involved somehow.

          Now to check whether this problem is in the IDE or grails... you can try to use grails from commandline (i.e. OS terminal window). Make sure to try it with grails interactive process so we are comparing apples to applles and not apples / oranges. The grails interactive process on commandline is started by just entering 'grails' as a command with nothing else after it.

          Try seeing if you get the same problem. If yes... then I'd say the bug is in Grails otherwise more likely its sometjing in GGTS.

          When we determine that we can decide what should do next to try to fix it.

          Comment


          • #6
            BTW: another tip. After running 'grails clean' command in GGTS. You can try to force a grails recompilation by doing 'Refresh Dependencie' from the Grails context menu. This will run the 'grails compile' command. If clean wasn't enough... this may do the trick.

            Still... no matter how you turn it. This seems like a bug. You shouldn't really need to clean or refresh-dependencies for changed code to be recompiled.

            Comment


            • #7
              Hi Kris, I just wanted to add I'm having a similar problem. I am using the GGTS (3.5.1 on Win8 x64) Grails 2.2.4 command prompt to run a Database Migration plugin schema gen script, and stale classes were surviving Grails clean, GGTS clean/build, F5 refreshes, refresh dependencies, etc - everything but restarting the IDE. Your suggestion to disable the long running Grails process worked for me. Sounds like the bug is as you suspect. It's slower, obviously, but a far better workaround than restarting the IDE constantly. Thanks!

              Comment

              Working...
              X