Description Valentin Baciu 2007-06-29 12:07:04 EDT

I thought about logging this against runtime since it's content type related but I figured I'd start up here in UI since it's a visible behaviour.

I was trying to verify whether an old WTP bug 107951 is still alive and kicking or not, and decided to try the scenario with WTP 2.0 (based on Eclipse 3.3).

What I noticed is that xsd and wsdl files from outside the workspace are not opened with the proper editor anymore, based on their content type. This used to work with WTP 1.5.4 (Eclipse 3.2.2). Instead of the WSDL and XSD editor the wsdl and xsd files are always opened with the XML editor.

I started to debug a bit thinking I may have run into another incarnation of our old friend bug 146951 -  wrong icons in the navigator. To avoid any WTP interference, I created a sample plug-in that tries to mimic the content type hierarchy declared by WTP. The WTP hierarchy looks like this:

org.eclipse.core.runtime.text
    org.eclipse.wst.xml.core.xmlsource - xml, xsd, wsdl extensions - XML source editor
    org.eclipse.core.runtime.xml - xml extension - XML source editor
        org.eclipse.wst.wsd.wsdlsource - wsdl extension	- WSDL editor
        org.eclipse.wst.xsd.core.xsdsource - xsd extension - XSD editor
			
So I created my test content type hierarchy to look like this:

org.eclipse.core.runtime.text
    maskingContentType - base,derived,third extensions - base editor
    baseContentType - base extension - base editor
        derivedContentType - derived extension - derived editor
        thirdContentType - third extension - third editor

I've been able to reproduce the WTP behaviour with my little example and through some debugging and experimentation I realized that the issue seems to be the fact that the wsdl and xsd extensions declared by the xmlsource content type are masking the ones declared lower in the hierarchy. Similarly the extensions declared in the maskingContentType are masking the derived and third extensions. Everything starts working by removing the extensions declared in xmlsource respectively in the maskingContentType. 

As a bonus, I also noticed that as soon as I removed the wsdl and xsd extensions from the xmlsource content type, the proper icons also showed up in the navigator - yay! Same with my little test.

I've also managed to find out why the two versions (3.2 and 3.3) are behaving differently. Here are two stack traces showing that opening an editor on an external file takes two different paths:
- the 3.2.2 code path uses this type of call to get the content type: Platform.getContentTypeManager().findContentTypeFor(stream, fileStore.getName()) 
- the 3.3 code path uses this type of call to get the content type: Platform.getContentTypeManager().findContentTypeFor(name) 

Further, the two code paths appear to use different content type matching policies: 
- the 3.2.2 code path uses a lexicographical policy org.eclipse.core.internal.content.ContentTypeCatalog.policyLexicographical 
- the 3.3 code path uses a "general is better" policy org.eclipse.core.internal.content.ContentTypeCatalog.policyGeneralIsBetter.

If I take the 3.2.2 case, I would venture to speculate that it worked by pure luck because somehow the more specific content type won in the lexicographic comparison.

In 3.3 the code seems to assume that the content types to be sorted are part of the same inheritance hierarchy. So the masking content type is found to be more generic than the derived content type by comparing their depths in the hierarchy.  In fact, they are in two different inheritance hierarchies. So even though they define the same extension and get lumped  together by the extension they define, they are not really parent/child.

$1000 question: What's wrong: the sorting code or the way WTP defines the hierarchy? 

Possible answers:
1) This works as designed and WTP is going outside the beaten path with using the same extension in two branches at different levels
2) The "general is better" sort policy is not accommodating this scenario

I'm opening the bug against the platform initially but based on the answer to the above question the bug may be reassigned to WTP, the wst.xml component. This information is also relevant to bug 146951 so I'll cross reference there.