Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 338568 - Resources incorrectly unloaded from resource set
Summary: Resources incorrectly unloaded from resource set
Status: VERIFIED FIXED
Alias: None
Product: WTP Common Tools
Classification: WebTools
Component: wst.common (show other bugs)
Version: 3.2.3   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.2.5   Edit
Assignee: Rosendo Martinez CLA
QA Contact: Carl Anderson CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-01 13:10 EST by Harold Gartner CLA
Modified: 2011-09-29 16:02 EDT (History)
2 users (show)

See Also:
ccc: review+


Attachments
Proposed fix to avoid resources incorrectly unloaded (1.62 KB, patch)
2011-03-29 16:08 EDT, Rosendo Martinez CLA
no flags Details | Diff
This patch contains a better fix for this defect (3.30 KB, patch)
2011-06-16 12:24 EDT, Rosendo Martinez CLA
ccc: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Harold Gartner CLA 2011-03-01 13:10:43 EST
Build Identifier: wtp-sdk-R-3.2.3-20110217214612

As part of the edit model used for our editor (which is an extension of org.eclipse.wst.common.internal.emfworkbench.integration.EditModel), there is an instance of the org.eclipse.wst.common.internal.emfworkbench.integration.ResourceSetWorkbenchEditSynchronizer class attached to the edit model.

When resources are deleted and then saved in our editor, the method ResourceSetWorkbenchEditSynchronizer.getResources(IFile aFile) is called to determine which resources to unload from the resource set.  It does this by comparing the URI of the IFile passed in to the resources in the resource set.  The method code is this:

	protected List getResources(IFile aFile) {

		List resources = new ArrayList();
		List allResources = resourceSet.getResources();
		for (Iterator iterator = allResources.iterator(); iterator.hasNext();) {
			Resource res = (Resource) iterator.next();
			URI resURI = res.getURI();
			String resURIString = ""; //$NON-NLS-1$
			if (resURI.path() != null) {
				IPath resURIPath;
				if (WorkbenchResourceHelper.isPlatformResourceURI(resURI))
					resURIPath = new Path(URI.decode(resURI.path())).removeFirstSegments(2);
				else
					resURIPath = new Path(URI.decode(resURI.path())).removeFirstSegments(1);
				resURIString = resURIPath.toString();
			}
			if (!resURIString.equals("") && aFile.getFullPath().toString().indexOf(resURIString) != -1) //$NON-NLS-1$
				resources.add(res);
		}
		return resources;
	}

The problem here is the last test in the loop which is doing this:

if (!resURIString.equals("") && aFile.getFullPath().toString().indexOf(resURIString) != -1) 

The problem is the use of 'indexOf' here.  This is incorrect.  An 'equals' call should be used here as using 'indexOf' will match similarly named resources and unload them from the resource set.  This erroneous unloading then causes our editor to behave erratically as many NPEs are hit as the 'eResource()' call on the resource in the resource set now returns a null value when it still should be loaded in the resource set.

The code should be like this:

if (!resURIString.equals("") && aFile.getFullPath().toString().equals(resURIString)) //$NON-NLS-1$

Here are some examples:

IFile passed in:
aFile.getFullPath().toString() == Export1.export
URI in resSet == Export1.exportex

This will match even thought the file extensions are different.

aFile.getFullPath().toString() == SCAExport1.export
URI in resSet == Export1.export

This will match even thought the file names are different.

Reproducible: Always
Comment 1 Rosendo Martinez CLA 2011-03-29 16:08:41 EDT
Created attachment 192128 [details]
Proposed fix to avoid resources incorrectly unloaded
Comment 2 Rosendo Martinez CLA 2011-06-16 12:24:50 EDT
Created attachment 198133 [details]
This patch contains a better fix for this defect
Comment 3 Carl Anderson CLA 2011-06-16 12:42:56 EDT
Committed to R3_2_maintenance for WTP 3.2.5.
Comment 4 Carl Anderson CLA 2011-07-08 13:57:23 EDT
Committed to HEAD for WTP 3.3.1 and WTP 3.4.0