The lesser of two JAXB weavils

[Benson Margulies <bi...@gmail.com>]

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

Re: The lesser of two JAXB weavils

[Benson Margulies <bi...@gmail.com>]

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 <bi...@gmail.com>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
>