That definitely falls into a JAXB area. I'm not really sure.
I would suggest firing the question off to the jaxb forum:
[EMAIL PROTECTED]
http://www.nabble.com/java.net---jaxb-users-f13500.html
They could probably help you more with that. There might be a
customization or something that would work, but I'm not really sure.
Dan
On Jun 20, 2008, at 3:29 PM, Gary Weaver wrote:
I should have tried this before posting, but I removed the multiple
sequences from SomeElementGType below so it looked like:
<xsd:complexType name="SomeElementGType">
<xsd:attribute fixed="DefaultValue" name="someAttribute"
type="xsd:string" use="required"/>
</xsd:complexType>
And cxf-codegen-plugin and JAXB were able to handle the WSDL fine
(or at least to generate and compile the resulting client code), so
that is definitely it.
Is there a way that anyone knows about to get cxf-codegen-plugin 2.1
with JAXB data binding to deal with multiple sequences in a row each
containing a reference to same type (see SomeElementGType below for
example), or whether a different data binding would be better to use?
For now, I'm going to focus on getting the developer to change the
service definition/wsdl, but may try switching to another data
binding type if he can't figure it out.
Thanks,
Gary
Gary Weaver wrote:
Hello,
Have been using Apache CXF cxf-codegen-plugin v2.1 in a project to
generate client code (using the default JAXB data binding) for a
few services and it worked has worked like a charm.
However, for the one I'm working on today, I got the following error:
[INFO] Thrown by JAXB : Element "{http://
my.services.namespace}ProblemElement" shows up in more than one
properties.
(note: I generified the namespace and element name in the error.)
Looking around for this error, I found a reference from Kenny
MacLeod on http://www.nabble.com/jaxb2---duplicate-element--issue-td16429810.html
stating "JAXB2 cannot generate code from that schema, sadly.
Consecutive elements of the same name have to be modelled as
sequences. "
Just for an example, could the following cause such an exception?
(There are many more references to "ProblemElement" in the WSDL,
unfortunately.) What about it would be the problem? It it the
multiple sequences in a row containing the same element type as
shown in SomeElementGType below? If not, could you guess at what
type of structure might cause this error?:
...
<xsd:complexType name="MyElementType">
<xsd:sequence>
<xsd:element minOccurs="0" name="SomeElementA"
type="SomeElementAType"/>
<xsd:element minOccurs="0" name="SomeElementB"
type="SomeElementBType"/>
<xsd:element minOccurs="0" name="SomeElementC"
type="SomeElementCType"/>
<xsd:element minOccurs="0" name="SomeElementD"
type="SomeElementDType"/>
<xsd:element minOccurs="0" name="SomeElementE"
type="SomeElementEType"/>
<xsd:element minOccurs="0" name="SomeElementF"
type="SomeElementFType"/>
<xsd:sequence maxOccurs="unbounded" minOccurs="0">
<xsd:element name="SomeElementG"
type="SomeElementGType"/>
<xsd:element minOccurs="0" name="ProblemElement"
type="ProblemElementType"/>
</xsd:sequence>
</xsd:sequence>
<xsd:attribute fixed="DefaultValue" name="someAttribute"
type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:complexType name="SomeElementGType">
<xsd:sequence>
<xsd:sequence maxOccurs="unbounded" minOccurs="0">
<xsd:element name="SomeElementH"
type="SomeElementHType"/>
<xsd:element minOccurs="0" name="ProblemElement"
type="ProblemElementType"/>
</xsd:sequence>
<xsd:sequence maxOccurs="unbounded" minOccurs="0">
<xsd:element name="SomeElementI"
type="SomeElementIType"/>
<xsd:element minOccurs="0" name="ProblemElement"
type="ProblemElementType"/>
</xsd:sequence>
<xsd:sequence maxOccurs="unbounded" minOccurs="0">
<xsd:element name="SomeElementJ"
type="SomeElementJType"/>
<xsd:element minOccurs="0" name="ProblemElement"
type="ProblemElementType"/>
</xsd:sequence>
</xsd:sequence>
<xsd:attribute fixed="DefaultValue" name="someAttribute"
type="xsd:string" use="required"/>
</xsd:complexType>
...
Thanks in advance for any help you can provide!
Gary
--
Gary Weaver
Internet Framework Services
Office of Information Technology
Duke University
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
