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
