ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Haberman (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IVYDE-332) launch file IVYDE_CONTAINER becomes invalid/stale when settings change
Date Tue, 18 Dec 2012 21:46:12 GMT
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

Mime
View raw message