cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject The lesser of two JAXB weavils
Date Fri, 27 Mar 2009 02:10:08 GMT
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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message