Reading the code of JAXB, I see that it purports to accept a customization with no schemaLocation, so I tried just removing the code in CustomizationParser that forced in the wsdlURL. Now JAXB complains on this case (testReuseJabBindingFile) that the XPath doesn't find anything. Perhaps the case is bad, I'll debug some more.
On Thu, Mar 26, 2009 at 10:10 PM, Benson Margulies <[email protected]>wrote: > Consider CodeGenBugTest.testReuseJabBindingFile1. > > This is a jaxb binding customization file with no schemaLocation at all. So > we substitute the wsdl location. And, in the code as currently on trunk, all > the wsdl files are 'keyed' by the wsdl URL, not the schema URL. > > If I cause files to be keyed by the actual schema URL, this fails. (Which > is a natural side-effect of disconnecting the DOM cache.) The JAX-WS > CustomizationParser finds no schema location, and substitutes the WSDL URL > instead (I wonder why all this isn't interconnected by TNS, instead). Since > no schema has a key of the WSDL URL, the result is a failure. > > However, it strikes me as sort of crazy to expect this to work. The JAXB > doc for parseSchema specifically demands a UNIQUE systemId as the key, and > we are very much not supplying one. Presumably, with no schemaLocation we're > trying to make it apply to all the schemas, but does JAXB really support > that? > > Perhaps a lack of a schema location should result in a multiplicity of > copies of the customization, one for each schema? > > > I could go push this wsdl location down through the XmlSchema meta info > map, and I guess the test would pass. > > However, I tried just removing the fragment from the key just before > passing it into JAXB, and another test failed. Just one case from the big > CodeGenBugTest, testLocatorWithJaxbBinding. The failure in this case to me > looks as if it is precisely caused by confusion between the various schemas > in the WSDL. > > So, I'd like to @Ignore the reuse test and check in, on the theory that >
