Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 154471

Summary:

WST code assumes IResource.getLocation() returns a non-null value

Product:

[WebTools] WTP Source Editing

Reporter:

John O'Shea <john.oshea>

Component:

wst.sse

Assignee:

Nitin Dahyabhai <thatnitind>

Status:

RESOLVED FIXED

QA Contact:

Nitin Dahyabhai <thatnitind>

Severity:

major

Priority:

CC:

csalter, david.black, david_williams, itewksbu

Version:

1.5

Target Milestone:

3.2 M4

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
HTTP EFS IFileSystem provider.	none
Sample XML file for deployment onto HTTP server.	none
Sample XML file for deployment onto HTTP server.	none
Sample XML file for deployment onto HTTP server.	none
Sample project (zipped) containing links to resources on a HTTP server.	none
Example patch of some mods I made to WST sse/xml code to eliminate NPE's	none

Description John O'Shea

2006-08-20 10:51:46 EDT

In a couple of places  

org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.calculateURIResolver
org.eclipse.wst.sse.core.internal.FileBufferModelManager.createURIResolver
org.eclipse.wst.xml.core.internal.validation.core.AbstractNestedValidator.validate

in the wst.sse and wst.xml code, when creating a URIResolver the code calls 

IResource.getLocation() but does not check the returned value for null.  

With the introduction of EFS in Eclipse 3.2, IResource.getLocation will return null if the resource is a link to a resource in another IFileSystem (e.g. a  file on a FTP server if the org.eclipse.core.filesystem.ftp prototype plugin is in use.)  The above code results in NullPointerExceptions, causing any SSE based editors (e.g. the XML or WSDL editors) to throw NullPointers when opening a linked resource.  This is causing us some problems as we rely on the WTP editors handling linked resources.

To reproduce:
1) Install plugins for an alternative IFileSystem implementation - see http://wiki.eclipse.org/index.php/EFS
2) Put some sample files (html & wsdl) into your filesytem backend (e.g. onto the FTP server if using the FTP plugin)
3) Create an empty simple project.
4) Edit the .project file and linkedResource entries:
    <linkedResources>
	    <link>
		    <name>index.html</name>
		    <type>1</type>
		    <locationURI>ftp//localhost/index.html</locationURI>
	    </link>
	    <link>
		    <name>hello.wsdl</name>
		    <type>1</type>
		    <locationURI>ftp://localhost/hello.wsdl</locationURI>
	    </link>
    </linkedResources>
5) Try opening the linked file int the workspace and then check the ErrorLog.

Note: You make need to pick up the patch mentioned at https://bugs.eclipse.org/bugs/show_bug.cgi?id=137878 if you want to use the FTP plugin. (I'm testing using a HTTP IFileSystem impl that I am writing).

See http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/porting/3.2/incompatibilities.html for more documentation ont the change of behavior in E3.2.  

In some places switching to IResource.getLocationURI() might be appropriate - I'm not sure as the expected value of URIResolver#fileBaseLocation is not javadoc'ed.  

FileBufferModelManager.createURIResolver() probably needs rework as it seems to have a special case for resources in the workspace (which might now be links to external resources).

Comment 1 John O'Shea

2006-09-12 11:59:26 EDT

I've reveiwed the steps I outlined below to double check them and actually found that the FTP file sytem implementation isn't the most reliable to use (especially with a Windows XP FTP server). Aplogies for that, I didn't realise as I was testing using a lightweight HTTP based EFS file system plugin*. I'm attaching a build of this HTTP IFilesystem plugin that may help simplify your reproducing this problem.

To reiterate, the problem is primarily that WTP XML/SSE editors cannot sucessfully open an XML IResource that is actually a workspace link to a URI that is resolved by a non-local EFS IFileSystem implementation.

To reproduce:
1) Install the attached com.capeclear.filesystem.http plugin in your eclipse runtime
2) Place the attached .wsdl and .xml files onto a local web server (e.g. local apache or tomcat server). The default root URL (assumed by the project below) is http://localhost:8000/)
3) Fire up Eclipse and import the attached testlink project.
4) If your HTTP server is not at the above URL, edit the .project file and change each <locationURI> element to point to the correct location for each resource.
5) In the Navigator view, try opening the linked files. You should notice NullPointerExceptions being logged to the Error Log as well as exception dialogs being presented to the user.

(By the way, I'm not yet certain what the little yellow decorator on the bottom right hand corner of link resource in the Navigator view signifies. It might be to signify that the resource is read-only as the underlying HTTP EFS filestore declares itself to be read-only. Either way, it is not relevant to this test scenario.)

The main problems that I'm seeing throughout the code are

1) General assumptions that IFile locations are always on the local file system. This is no longer the case in Eclipse 3.2, hence IResource.getLocation() returning null.

2) There seems to be quite a lot of URIResolver related code that assumes that XML/WSDL <import> element "location" attributes only contain URLs that can ultimately be resolved to a path on the local file system. This assumption is invalid - import locations can be any valid URL (e.g. http://) as i the examples above.

I'm attaching a number of example patches for various classes in WST SSE and WST XML that I've had to modify in order to get rid of the NullPointerExceptions while simply loading linked resources.

I'm afraid I'm not certain that these patches don't break other pieces of the editors (specifically the URI Resolver code) so I don't think they are suitable as-is. However, they do allow me to open and validate files that are loaded via my HTTP IFileSystem so they might be an interim improvment if they do not break any existing functionality. Those more familiar with the SSE/XML code would know better.

* The source for this HTTP based file system will be made publically available via a CVS server on developer.capeclear.com later this week hopefully. For the moment you can assume that the implementation will happily attempt to load any HTTP:// resource you point it at (from any HTTP 1.0 compliant server)

Comment 2 John O'Shea

2006-09-12 12:00:32 EDT

Created attachment 49941 [details]
HTTP EFS IFileSystem provider.

See comment #2

Comment 3 John O'Shea

2006-09-12 12:03:05 EDT

Created attachment 49943 [details]
Sample XML file for deployment onto HTTP server.

Comment 4 John O'Shea

2006-09-12 12:03:24 EDT

Created attachment 49944 [details]
Sample XML file for deployment onto HTTP server.

Comment 5 John O'Shea

2006-09-12 12:03:37 EDT

Created attachment 49945 [details]
Sample XML file for deployment onto HTTP server.

Comment 6 John O'Shea

2006-09-12 12:05:09 EDT

Created attachment 49946 [details]
Sample project (zipped) containing links to resources on a HTTP server.

Comment 7 Nitin Dahyabhai

2006-09-12 13:59:43 EDT

CCing Craig so he can follow along on any URI Resolver-related issues.

Comment 8 John O'Shea

2006-09-13 04:32:03 EDT

Created attachment 50013 [details]
Example patch of some mods I made to WST sse/xml code to eliminate NPE's

(Forgot to attach this yesterday)
Note, I'm not suggesting this patch is a complete fix.  I think the sse/xml code need a more complete review to identify the correct solutions - there seems to be quite a few areas where the assumptions outlined in this bug were made.  

These patches "work for me" in the scenarios I am testing, though might break some other use cases.

Comment 9 John O'Shea

2006-09-14 04:50:07 EDT

The source code for the HTTP EFS IFileSystem provider is now available at 

http://developer.capeclear.com/?q=cvsrepo

if you want it...

Comment 10 Ian Tewksbury

2010-02-01 16:56:38 EST

As of WTP 3.2

ModelManagerImpl#calculateURIResolver checks for null
FileBufferModelManager#createURIResolver does not use IResource.getLocation() but uses IFileBuffer#getLocation which should not be an issue because a file buffer should always have a location
AbstractNestedValidator.validate does check for null

Thus it is about time this one get resolved.

Comment 11 Nitin Dahyabhai

2010-02-02 16:49:49 EST

(In reply to comment #10)
> As of WTP 3.2
> 
> ModelManagerImpl#calculateURIResolver checks for null
> FileBufferModelManager#createURIResolver does not use IResource.getLocation()
> but uses IFileBuffer#getLocation which should not be an issue because a file
> buffer should always have a location
> AbstractNestedValidator.validate does check for null
> 
> Thus it is about time this one get resolved.

Actually #getLocation() is still called, but it is checked for null when doing so.  Resolving courtesy of the last fix in bug 296022.