Bugzilla – Full Text Bug Listing
| Summary: | IResource.getLocationURI(...) throws a ClassCastException | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas . <spam-receiver> | ||||||
| Component: | Resources | Assignee: | James Blackburn <jamesblackburn+eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | cdtdoug, jamesblackburn+eclipse, Szymon.Brandys | ||||||
| Version: | 3.6 | Flags: | Szymon.Brandys:
review+
|
||||||
| Target Milestone: | 3.7 M4 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Thomas .
Does your log file contain the stack-trace for the exception? <your workspace>/.metadata/.log Created attachment 181370 [details]
Workspace log file containing a stack trace for the exception.
Thanks, the root cause is that IResource.getLocationURI(...) throws the class cast exception: java.lang.ClassCastException: org.eclipse.core.internal.resources.File cannot be cast to org.eclipse.core.resources.IContainer at org.eclipse.core.internal.localstore.FileStoreRoot.getManager(FileStoreRoot.java:66) at org.eclipse.core.internal.localstore.FileStoreRoot.computeURI(FileStoreRoot.java:82) at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:659) at org.eclipse.core.internal.resources.Resource.getLocationURI(Resource.java:1132) at org.eclipse.cdt.internal.core.model.CModelManager.createBinaryFile(CModelManager.java:671) Serge, could you look at it? FileStoreRoot#getManager was introduced along with Dynamic Path Variables. This is interesting and I've just come across this. It looks like in the view the model is showing an IFile nested within an IFile, and then trying to get the location of the nested file. So at: FileStoreRoot.getManager(IPath) line: 66 workspacePath = /project/Library_Build/libfoo.a/foo.o path = /project/Library_Build/libfoo.a resource = L/project/Library_Build/libfoo.a The path to foo.o is invalid (in the filesystem), so the interesting thing would be whether #getLocationURI should return null or return a location as it does for non-existent files... The API isn't clear on which would be preferred -- and I can think of arguments for both. Created attachment 182060 [details]
fix + test 1
Potential fix + test; simplifies FileStoreRoot#getManager().
Looking at the code, there are three paths through it:
1) If the IResource exists, then #findMember will be none-null and and return resource.getPathVariableManager.
2) If the IResource doesn't exist, but a parent does exist, then the resource is treated as a file, and the path variable manager for that is returned.
3) If a parent doesn't exist, then the WR path variable manager is returned.
I believe the second 2 are equivalent, as the ProjectPathVariableManager seems to fall-back to the workspace PathVariableManager when the project can't be found. (Of course if it ever doesn't, then this is likely a bug...)
The attached patch therefore simplifies the logic. Returning the resource's PVM if it exists, otherwise a PVM for the resource treated as a WS relative file.
Serge what do you think?
Fixed. Thanks James. |