Writing a correct XPath in the bindings file doesn't help. - Just for the
record, with the Schema sample posted here, the correct bindings file would
be as shown below - note the [position()=2] to contrain the path to the 2nd
sub-<sequence>):
<jaxb:bindings xmlns:jaxb="
http://java.sun.com/xml/ns/jaxb"
xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
jaxb:version="2.0">
<jaxb:bindings schemaLocation="dupl.xsd" node="/xsd:schema">
<jaxb:bindings
node="//xsd:complexType[@name='TypeShape']/xsd:sequence/xsd:sequence[position()=2]/xsd:element[@name='PSCAMA']">
<jaxb:property name = "PSCAMA1">
</jaxb:property>
</jaxb:bindings>
</jaxb:bindings>
</jaxb:bindings>
It seems that JAXB is not prepared to handle epnoymous elements based on
their relative position to other elements, i.e., SCC_SM_RULE_VW and
SCC_SM_PRSN_VW.
Offhand, the only solution for producing JAXB code that's capable of
unmarshalling an XML file according to this schema would be to use an
alternative definition of that unspeakable type
name="SCC_SM_SERVICEMsgDataRecord_TypeShape". Note that this is not a
*change* of the original schema, merely a rewrite which will marshal and
unmarshal XML data still compliant with the original schema, (provided the
list is created correctly, in accordance with that original schema).
This is the alternative type definition:
<xsd:complexType name="SCC_SM_SERVICEMsgDataRecord_TypeShape">
<xsd:sequence>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="SCC_SM_RULE_VW" type="xsd:string" />
<xsd:element name="SCC_SM_PRSN_VW" type="xsd:string" />
<xsd:element name="PSCAMA" type="xsd:string"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
and this is part of the generated Java code:
public class ...TypeShape {
protected List<JAXBElement<String>> sccsmrulevwOrSCCSMPRSNVWOrPSCAMA;
public List<JAXBElement<String>> getSCCSMRULEVWOrSCCSMPRSNVWOrPSCAMA() {
if (sccsmrulevwOrSCCSMPRSNVWOrPSCAMA == null) {
sccsmrulevwOrSCCSMPRSNVWOrPSCAMA = new
ArrayList<JAXBElement<String>>();
}
return this.sccsmrulevwOrSCCSMPRSNVWOrPSCAMA;
}
}
All sub-elements of an element of that type are in this List<JAXBElement>,
and processing it (after unmarshalling) will require to keep track of
whether you are after an SCC_SM_RULE_VW or an SCC_SM_PRSN_VW to associate
the PSCAMA with their respective predecessor. (This wouldn't be different if
JAXB could handle the original type definition.)
-W
On 3 August 2010 22:40, Glen Mazza <glen.mazza_at_gmail.com> wrote:
> Was the latest answer I provided (
> http://forums.java.net/jive/thread.jspa?messageID=479242#479242) not
> correct? (It may not have been, I'm not an expert at this.)
>
> Glen
>
>
> Kris Easter wrote:
>
>> I'm trying to parse a XSD with JAXB that has elements with the same name
>> inside sequences inside a complex type. I posted a variant on the
>> problem on the Metro web forum using wsimport but I think I've got it
>> narrowed down to a JAXB question so I thought I'd ask about it here.
>> Hopefully this won't be considered a cross-post.
>>
>> With this:
>>
>> xjc TestRepeatingSchema.xsd
>> I get this:
>>
>> [ERROR] Element "{http://www.example.org/TestRepeatingSchema}PSCAMA<http://www.example.org/TestRepeatingSchema%7DPSCAMA>
>> "
>> shows up in more than one properties.
>>
>> I've tried adding in line annotations like:
>>
>> <xsd:element minOccurs="0" name="PSCAMA" type="xsd:string">
>> <xsd:annotation>
>> <xsd:appinfo>
>> <jxb:property name="PSCAMA1" />
>> </xsd:appinfo>
>> </xsd:annotation>
>> </xsd:element>
>>
>> And a similar approach with a .xjb file. The inline annotations result
>> in:
>>
>> [ERROR] compiler was unable to honor this property customization. It is
>> attached to a wrong place, or its inconsistent with other bindings.
>>
>> The .xjb file throws an xpath violation:
>>
>> [ERROR] XPath evaluation of ".//xs:element[@name='PSCAMA']" results in
>> too many (2) target nodes
>>
>> Can someone tell me what I'm doing wrong and how to get JAXB to parse
>> this correctly? I believe it's a "valid" schema but if it's not I can
>> at least take that back to the developer of the webservice and see if
>> they'll change the schema.
>>
>> A sample schema that shows the problem is:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <xsd:schema xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
>> jxb:version="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> targetNamespace="http://www.example.org/TestRepeatingSchema"
>> xmlns="http://www.example.org/TestRepeatingSchema"
>> elementFormDefault="qualified">
>>
>> <xsd:complexType name="SCC_SM_SERVICEMsgDataRecord_TypeShape">
>>
>> <xsd:sequence>
>>
>> <xsd:sequence minOccurs="0" maxOccurs="unbounded">
>> <xsd:element name="SCC_SM_RULE_VW" type="xsd:string" />
>> <xsd:element minOccurs="0" name="PSCAMA" type="xsd:string"/>
>> </xsd:sequence>
>>
>> <xsd:sequence minOccurs="0" maxOccurs="unbounded">
>> <xsd:element name="SCC_SM_PRSN_VW" type="xsd:string" />
>> <xsd:element minOccurs="0" name="PSCAMA" type="xsd:string">
>>
>> <!--<xsd:annotation>
>> <xsd:appinfo>
>> <jxb:property name="PSCAMA1" />
>> </xsd:appinfo>
>> </xsd:annotation>
>> -->
>> </xsd:element>
>>
>> </xsd:sequence>
>> </xsd:sequence>
>> </xsd:complexType>
>>
>> </xsd:schema>
>>
>> Thanks for any help you can offer.
>>
>> Kris
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>