[jira] [Created] (IVYDE-332) launch file IVYDE_CONTAINER becomes invalid/stale when settings change

["Stephen Haberman (JIRA)" <ji...@apache.org>]

Stephen Haberman created IVYDE-332:
--------------------------------------

             Summary: launch file IVYDE_CONTAINER becomes invalid/stale when settings change
                 Key: IVYDE-332
                 URL: https://issues.apache.org/jira/browse/IVYDE-332
             Project: IvyDE
          Issue Type: Bug
          Components: launch configuration
    Affects Versions: trunk
            Reporter: Stephen Haberman


Our apps (when ran from .launch files) started getting a bunch of ClassNotFoundExceptions today.

Stepping into IvyDE, I figured out what went wrong...

1. Our .classpath has a IVYDE_CONTAINER/?project=...&foo

2. Our .launch files have cp entries of IVYDE_CONTAINER/?project=...&foo (so far, so good, everything works great)

3. When we changed some IvyDE settings in our .classpath file, the entry in the .classpath file changed to IVYDE_CONTAINER/?project=...&bar (still the same project, but the setting suffixes were different).

4. When we Hit resolve, IvyClasspathContainer:166 updates the CP entry (JavaCore.setClasspathContainer(path, ...)) *with the new path* (?project=...&bar).

5. When we ran our .launch files, IvyDERuntimeClasspathEntryResolver used the *old* path still in the .launch file to look up the container, which unfortunately actually worked, because Eclipse had the serialized state of  he old path/container saved, so the stale container got used to run our program.

6. The stale IvyClasspathContainer had some jars in it that, in the new IvyClasspathContainer were imported via the workspace resolve (so the underlying jars were deleted from the local retrieve directory) so led to the CNFEs in our code.

So...the problem seems like path should not be used for the identifying key of the IVYDE_CONTAINER, since it is likely to easily change, leading to .launch files getting their containers references becoming invalid and so the contents stale.

Perhaps a subset of the path could be used (like only project name + confs?) when putting IVYDE_CONTAINER references in the .launch file.

Or maybe some unique index (or ID) could be added to the path (only when in the .launch file, like /?project=...&index=0), and the runtime look up could ignore the JavaCore method that may return an old/stale container, and manually search for the possibly-updated container with the right index?

For now I'll update our launch files with the new path, but any ideas for a more future proof solution would be appreciated.

Thanks!



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira