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
