Spring Roo
  1. Spring Roo
  2. ROO-357

workdir jars not removed on addon uninstall on Windows

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0.RC3
    • Fix Version/s: 1.0.0.RC4
    • Component/s: @ CORE
    • Labels:
      None
    • Environment:
      Windows XP SP3 with Sun jdk1.6.0_16

      Description

      Addon jars remain in the work dir after an addon uninstall on Windows. AddOnOperations.cleanUp() uses File.deleteOnExit() for the deletion: my guess is that these files are still locked when the JVM tries to remove them because these jars are listed in java.ext.dirs, and Windows supports locking files that are in use.
      The only solution I can come up with is that Roo should create a simple text file containing the files to delete and would leave it up to the roo.bat script to delete these files before starting the JVM (could even be done by another Java program started by the script instead of a 'del' command, as long as that JVM command doesn't list the work dir in the java.ext.dirs).
      Every Java-based solution running just in the Roo JVM will suffer from the fact that the jars are locked already by the same JVM that tries to remove them, so this takes more than a simple code patch; a 2-step process in the .bat file seems like the best bet to me.

        Issue Links

          Activity

          Hide
          Joris Kuipers added a comment -

          I think solving the issue in the .bat is certainly the easiest and safest solution: just use 'addon cleanup' for now, it wouldn't be too hard to change that to a focused deletion of files later on if that would be preferable.
          There should probably be a note in the guide that mentions that addon uninstall will not work properly on Windows when you have multiple Roo shells open, as they will keep the files locked. The code that performs the 'addon cleanup' could check for lingering files and print out an error if the work dir cannot be cleaned out. It means users will have to delete files manually, so the error should list them.

          Show
          Joris Kuipers added a comment - I think solving the issue in the .bat is certainly the easiest and safest solution: just use 'addon cleanup' for now, it wouldn't be too hard to change that to a focused deletion of files later on if that would be preferable. There should probably be a note in the guide that mentions that addon uninstall will not work properly on Windows when you have multiple Roo shells open, as they will keep the files locked. The code that performs the 'addon cleanup' could check for lingering files and print out an error if the work dir cannot be cleaned out. It means users will have to delete files manually, so the error should list them.
          Hide
          Ben Alex added a comment -

          Excellent. Would you like to tackle this one Joris or should I? I don't mind either way.

          Show
          Ben Alex added a comment - Excellent. Would you like to tackle this one Joris or should I? I don't mind either way.
          Hide
          Joris Kuipers added a comment -

          I can have a go at it: would you like to introduce an extra ExitShellRequest entry with a custom error code for cleanup, or do you simply always want to do this in the .bat file when a code 100 is being returned, so also after installing a new addon?

          Show
          Joris Kuipers added a comment - I can have a go at it: would you like to introduce an extra ExitShellRequest entry with a custom error code for cleanup, or do you simply always want to do this in the .bat file when a code 100 is being returned, so also after installing a new addon?
          Hide
          Ben Alex added a comment -

          It really depends on whether it affects STS or not. If you could ask Christian his thoughts it would be good. I agree it'd be cleaner to have a dedicated exit code to save complex batch file processing, but if it breaks STS I think complex batch file processing is better than requiring an STS change.

          Show
          Ben Alex added a comment - It really depends on whether it affects STS or not. If you could ask Christian his thoughts it would be good. I agree it'd be cleaner to have a dedicated exit code to save complex batch file processing, but if it breaks STS I think complex batch file processing is better than requiring an STS change.
          Hide
          Joris Kuipers added a comment -

          Fixed in SVN Rev 455; added new exit code 200 that will trigger a clean of the work dir on Windows using the roo[-dev].bat file. Means that Roo shell in STS 2.2.1 will not restart anymore after deleting an addon, but the restart didn't help anyway as the jars in the work dir are not removed. New Roo plugin will do the same on Windows as the new bat files, for now I advice Windows users working against trunk to use the command line shell for addon uninstall.
          *nix scripts have been updated to check for exit code 0 for restarts instead of exit code not being 100.

          Show
          Joris Kuipers added a comment - Fixed in SVN Rev 455; added new exit code 200 that will trigger a clean of the work dir on Windows using the roo [-dev] .bat file. Means that Roo shell in STS 2.2.1 will not restart anymore after deleting an addon, but the restart didn't help anyway as the jars in the work dir are not removed. New Roo plugin will do the same on Windows as the new bat files, for now I advice Windows users working against trunk to use the command line shell for addon uninstall. *nix scripts have been updated to check for exit code 0 for restarts instead of exit code not being 100.

            People

            • Assignee:
              Joris Kuipers
              Reporter:
              Joris Kuipers
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: