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

Bug 325951

Summary: [XML Catalog] Content assist doesn't use namespaces mapped in a catalog file
Product: [WebTools] WTP Source Editing Reporter: James Phillpotts <james.phillpotts>
Component: wst.xmlAssignee: wst.xml <wst.xml-inbox>
Status: NEW --- QA Contact: Nick Sandonato <nsand.dev>
Severity: normal    
Priority: P3 CC: keith.chong.ca, rakes123
Version: unspecified   
Target Milestone: Future   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Test xml file
none
Test catalog file
none
patch
none
new patch none

Description James Phillpotts CLA 2010-09-22 08:05:12 EDT 
Build Identifier: Build id: 20100617-1415

I'm trying to use a catalog file to define the locations of XSDs that are generated on a CI server for namespaces used in project XML files.

If I use a namespace, say "test://dummy.namespace", and then specify the real location of the XSD in a catalog file, configured as a Delegate for "test://" (or as Next catalog), content assist does not offer any suggestions, etc. for the elements in that namespace.

I will attach a simple example.

Reproducible: Always

Steps to Reproduce:
1. Create a new project, test
2. Add the two xml files to the project (to be attached)
3. Add a user-specified Delegate XML Catalog for start string "test://" to catalog file test/test-catalog.xml
4. In test.xml try to use content assist with and without xsd: namespace - both should present the same set of tags, but only xsd: is resolved.
Comment 1 James Phillpotts CLA 2010-09-22 08:07:27 EDT 
Created attachment 179371 [details]
Test xml file
Comment 2 James Phillpotts CLA 2010-09-22 08:07:57 EDT 
Created attachment 179372 [details]
Test catalog file
Comment 3 Rakesh CLA 2010-11-12 00:06:56 EST 
Created attachment 182954 [details]
patch

Our catalog resolver is resolving "test://this.is.a.catalog.test.uri" to "http://www.w3.org/2001/XMLSchema", which is correct for given catalog.So it goes to internet cache to get result and content assist fails.
If we use "http://www.w3.org/2001/XMLSchema" directly in test.xml , then it will be resolved to a jar file locally which contains all schemas etc , and content assist works.
If resolved uri is in http protocol, we should try to resolve it again in hope to find it in local jar file.
Comment 4 Rakesh CLA 2010-11-12 04:02:10 EST 
Created attachment 182965 [details]
new patch

removed change in URIHelper, which is not in our plugin.
Comment 5 James Phillpotts CLA 2010-11-12 05:48:01 EST 
(In reply to comment #3)
> If we use "http://www.w3.org/2001/XMLSchema" directly in test.xml , then it
> will be resolved to a jar file locally which contains all schemas etc , and
> content assist works.
> If resolved uri is in http protocol, we should try to resolve it again in hope
> to find it in local jar file.

Perhaps XMLSchema was a bad example for the simple test case if it is resolved to a jar file - I find this bug to exist for other XSDs that only exist at the end of the http location.
Comment 6 Rakesh CLA 2010-11-18 05:24:25 EST 
 Looks like CacheURIResolverExtension is resolving 'http://www.w3.org/2001/XMLSchema' to a wrong cached element.It is not a xsd at all.Maybe it is getting confused with this particluar url.Could you add another example for us?
Valentin, is there anything specific we should be aware of while trying to fetch an xsd from internet?
Comment 7 Nick Sandonato CLA 2011-04-13 10:11:05 EDT 
Comment on attachment 182965 [details]
new patch

It sounds like this patch is obsolete based on the last two comments.
Comment 8 Nick Sandonato CLA 2014-04-24 00:29:33 EDT 
This won't be making it into Luna, unless someone wants to pick it up.