Johnny Tolliver wrote:
> I apologize if this is a simple question, but I've stared at XPath
> documentation and XJB customization documentation for a couple of hours and
> tried a lot of things, but I've run out of ideas.
>
> I'm trying to use JAXB 2.0 to compile some highly interdependent schema files,
> all of which are out of my control, and I'm getting name conflicts. So far, my
> attempts to resolve the collisions using an external customizations file have
> failed. Can someone help?
>
> Here's an excerpt of the offending file:
>
> 293 <element name="graphStyle" type="gml:GraphStylePropertyType">
> 294 <annotation>
> 295 <documentation/>
> 296 </annotation>
> 297 </element>
>
> 312 <element name="GraphStyle" type="gml:GraphStyleType" substitutionGroup="gml:_GML">
> 313 <annotation>
> 314 <documentation>xxx</documentation>
> 315 </annotation>
> 316 </element>
>
>
> Note that on line 293 there is an element named 'graphStyle' while line 312
> has an element named 'GraphStyle', differing only in the capitalization of the
> first letter and in type. I get an error message from xjc about two
> declarations causing a collision in the ObjectFactory class. The error message
> references lines 293 and 312.
>
> I'm assuming that the above is legal, if questionable, schema syntax. But in
> any case, since the schema source is out of my control, my only recourse is to
> try to fix it with an external customization file. I'm also assuming that the
> collision is due to the two nearly-identical names GraphStyle and graphStyle.
Yes. So far all correct.
> I've first tried a customization file like this, attempting to change the
> first, lowercase, graphStyle to some other name.
>
> <jxb:bindings schemaLocation="whatever"
> node=".//xs:element[@name='graphStyle']">
> <jxb:property name="SomeNewName"/>
> </jxb:bindings>
You needed <jaxb:class> customization. My workspace version of the JAXB
RI reports an error like this:
A class/interface with the same name "generated.Foo" is already in
use. Use a class customization to resolve this conflict.
... which points you toward the class customization.
In 2.1, with SCD support, I hope to improve the error messages to
actually propose a customization snippet you can use to resolve the
conflict.
> This did not help. Then, thinking that maybe XPath wasn't honoring the
> capitaliation, I tried further refining the XPath expression to select on the
> type attribute too:
If your XPath was wrong (such as not matching anything or matched more
than one things), then XJC would have told you so.
Also, you can use "-mode forest" to see the schema after applying all
external customizations, if you absolutely want to verify that your
XPath is correct.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com