Bugzilla – Full Text Bug Listing
| Summary: | Failure when importing a WSDL file in another WSDL for WTP > M4 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Webservices | Reporter: | Nicolas Mailhot <nicolas.mailhot> | ||||||||||||||
| Component: | wst.wsdl | Assignee: | Nitin Dahyabhai <thatnitind> | ||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||||||
| Severity: | critical | ||||||||||||||||
| Priority: | P2 | CC: | david_williams, lmandel | ||||||||||||||
| Version: | 0.7 | ||||||||||||||||
| Target Milestone: | 1.0 M6 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows 2000 | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Nicolas Mailhot
Nicholas, can you please supply WSDL files that demonstrate this problem and attach them to this bug? Reproduced with WTP 0.7RC1 Attached two simple wsdl that serve as test case. Just put them in the same dir and validate the test one Created attachment 25033 [details]
Imported wsdl
Created attachment 25034 [details]
Importing wsdl
Created attachment 25123 [details]
Additional test case
(In reply to comment #0) I have encountered same bug, having migrated from WTP 1.0 M4 to M5 - identical warning/error. warning: The '.ProjectStuff/wsdl' document could not be imported. Check that the document exists and that the location is correct. This then led to further warning/error in other schemas as it failed to read references to the File.wsdl document. Attached sample files as 103306-ab.zip Changing severity to P2. This is a significant problem for the WSDL validator. Fixed in RC2. Fix committed 20050721 7:15pm EDT. Problem still observed in nightly build on Friday 22 July and also in more recent 0.7RC3. Workaround is to use M4 (or earlier) release. Sent real wsdl by email to Lawrence (not uploaded due to confidential status). Note - I have insufficient priviledge to reopen bug. Just ask Alexis, I checked the sample docs you attached to this bug report. The namespace in PStructDo.xsd is defined incorrectly (based on how it is imported into the other documents). Changing the target namespace from http://www.projectstuff.org/schemas/version02/PStructDo.xsd to http://www.projectstuff.org/schemas/version00/PStructDo.xsd allows all the files to validate correctly. Nicolas, can you reproduce this problem on RC3? Alexis (and Nicolas) can you tell me what Java runtime you are using? Created attachment 25287 [details]
The files Alexis provided in a Web project
The problem only occurs in Web projects. This Web project reproduces the
problem.
The source of the problem is the component resolver which was added between M4 and M5. The resolver returns local results with the "file://" protocol which, as the comments in the resolver itself state, "On Win32, 2 slashes results in a URL object where the volume is stripped out of the file path as the host name" This causes the XSD and WSDL validators to fail for the Web project I've attached. The fix is to change the private static final String FILE_PROTOCOL = "file://"; //$NON-NLS-1$ to private static final String FILE_PROTOCOL = "file:///"; //$NON-NLS-1$ Nitin, I'm reassigning to you as from what I can tell you own this component. Is there a reason the component resolver uses two slashes? Is there a reason the component resolver is doing simple resource resolution (in this case, just relative to the base directory) when the URI resolver framework already handles this case? I'm marking as critical as this defect breaks WSDL and XSD validation in Web projects. +1 In case it still makes a difference I'm using Sun 1.5.0_03-b07 under win32. My next WTP download window will be the 28 (western europe time) Lawrence, the resolver is doing the relative resolution because the relative paths in the workspace won't necessarily be the same paths as on the server. The use of two slashes came from debugging the common resolver results on Windows and Linux and finding that the resulting number of slashes was inconsistent across platforms if the query itself didn't begin with two slashes. The use of two slashes was adopted in the SSE FileBufferModelManager.CommonURIResolver for that reason and the ComponentResolver was written to handle two slashes as a result. Changing both classes to use three slashes appears to have the desired behavior, now. Created attachment 25310 [details]
patch for ComponentResolver
Created attachment 25311 [details]
patch for FileBufferModelManager
Committing. David please release. I can confirm my testcase works with RC4 Tested OK on both 0.7RC4 and 0.7RC5. Nice work! I'm changing the bug status to verified as both Nicolas and Alexis have verified the fix. Closing bug. |