[
https://issues.apache.org/jira/browse/CXF-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782703#comment-13782703
]
Grzegorz Grzybek edited comment on CXF-5254 at 10/1/13 5:52 PM:
----------------------------------------------------------------
In {{cxf/testutils/src/main/resources/wsdl/type_test/type_test.xsd}}
(not-generated resourece) there is:
{code:xml}
<complexType name="CompoundArray">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="array1"
type="string"/>
<element maxOccurs="unbounded" minOccurs="0" name="array2"
type="string"/>
</sequence>
</complexType>
{code}
which translates to the following JAXB class:
{code:java}
public class CompoundArray {
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array1;
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array2;
...
{code}
However from Juergen's IDL:
{code}
typedef sequence<string> Strings;
typedef sequence<long> Longs;
struct Deep {
long id;
Strings s1;
};
{code}
generated WSDL has:
{code:xml}
<xs:complexType name="repro.Strings">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="item"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
...
<xs:complexType name="repro.Deep">
<xs:sequence>
<xs:element name="id" type="xs:int"/>
<xs:element name="s1" type="repro.Strings"/>
</xs:sequence>
</xs:complexType>
{code}
and *not*:
{code:xml}
<xs:complexType name="repro.Deep">
<xs:sequence>
<xs:element name="id" type="xs:int"/>
<xs:element name="item" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
{code}
and the resulting JAXB class is:
{code:java}
public class ReproDeep {
protected int id;
@XmlElement(required = true)
protected ReproStrings s1;
{code}
that's why JAXB expects {{s1}} element and that's why I thought
{{CorbaSequenceEventProducer}} would be better than
{{CorbaPrimitiveSequenceEventProducer}}.
at runtime however (in {{if ((obj instanceof CorbaSequenceHandler) ...}}
condition) I can't however distinguish between these two cases.
I don't think cxf-corbatools-maven-plugin should _unwrap_:
{code:xml}
<xs:element name="s1" type="repro.Strings"/>
{code}
into
{code:xml}
<xs:element name="item" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
{code}
When I've changed the generated {{org.apache.type_test.types1.CompoundArray}}
(in {{cxf-testutils}}) from:
{code:java}
public class CompoundArray {
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array1;
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array2;
{code}
to:
{code:java}
public class CompoundArray {
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
@XmlElementWrapper(name = "array1")
protected List<String> array1;
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
@XmlElementWrapper(name = "array2")
protected List<String> array2;
{code}
(to simulate explicit complex types for CORBA sequences with
{{@XmlElementWrapper}}), both CXF tests and Juergen's case worked fine.
Maybe just change {{CompoundArray}} complex type in
{{/cxf-testutils/src/main/resources/wsdl/type_test/type_test.xsd}} - it doesn't
seem to be generated...
regards
Grzegorz Grzybek
was (Author: gzres):
In {{cxf/testutils/src/main/resources/wsdl/type_test/type_test.xsd}}
(not-generated resourece) there is:
{code:xml}
<complexType name="CompoundArray">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="array1"
type="string"/>
<element maxOccurs="unbounded" minOccurs="0" name="array2"
type="string"/>
</sequence>
</complexType>
{code}
which translates to the following JAXB class:
{code:java}
public class CompoundArray {
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array1;
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array2;
...
{code}
However from Juergen's IDL:
{code}
typedef sequence<string> Strings;
typedef sequence<long> Longs;
struct Deep {
long id;
Strings s1;
};
{code}
generated WSDL has:
{code:xml}
<xs:complexType name="repro.Strings">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="item"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
...
<xs:complexType name="repro.Deep">
<xs:sequence>
<xs:element name="id" type="xs:int"/>
<xs:element name="s1" type="repro.Strings"/>
</xs:sequence>
</xs:complexType>
{code}
and *not*:
{code:xml}
<xs:complexType name="repro.Deep">
<xs:sequence>
<xs:element name="id" type="xs:int"/>
<xs:element name="item" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
{code}
and the resulting JAXB class is:
{code:java}
public class ReproDeep {
protected int id;
@XmlElement(required = true)
protected ReproStrings s1;
{code}
that's why JAXB expects {{s1}} element and that's why I thought
{{CorbaSequenceEventProducer}} would be better than
{{CorbaPrimitiveSequenceEventProducer}}.
at runtime however (in {{if ((obj instanceof CorbaSequenceHandler) ...}}
condition) I can't however distinguish between these two cases.
I don't think cxf-corbatools-maven-plugin should _unwrap_:
{code:xml}
<xs:element name="s1" type="repro.Strings"/>
{code}
into
{code:xml}
<xs:element name="item" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
{code}
When I've changed the generated {{org.apache.type_test.types1.CompoundArray}}
(in {{cxf-testutils}}) from:
{code:java}
public class CompoundArray {
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array1;
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
protected List<String> array2;
{code}
to:
{code:java}
public class CompoundArray {
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
@XmlElementWrapper(name = "array1")
protected List<String> array1;
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2013-10-01T06:40:47+02:00", comments = "JAXB RI v2.2.6")
@XmlElementWrapper(name = "array2")
protected List<String> array2;
{code}
both CXF tests and Juergen's case worked fine.
Maybe just change {{CompoundArray}} complex type in
{{/cxf-testutils/src/main/resources/wsdl/type_test/type_test.xsd}} - it doesn't
seem to be generated...
regards
Grzegorz Grzybek
> Unmarshall exception if a sequence<string> is used in a struct.
> ---------------------------------------------------------------
>
> Key: CXF-5254
> URL: https://issues.apache.org/jira/browse/CXF-5254
> Project: CXF
> Issue Type: Bug
> Components: CORBA Binding
> Affects Versions: 2.7.5, 2.7.6
> Environment: JAVA7 / Windows 7
> Reporter: Juergen Bockhorn
> Priority: Blocker
> Attachments: CorbaBugRepro.zip
>
>
> A server function returns a struct. This struct contains another struct which
> contains a sequence<string>. Calling this method with a CXF/Corba-Client
> leads to an unmarshall exception:
> {code}
> Warnung: Interceptor for
> {http://cxf.apache.org/bindings/corba/idl/repro}repro.ServiceCORBAService#{http://cxf.apache.org/bindings/corba/idl/repro}getFirst
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: unerwartetes Element
> (URI:"", lokal:"item"). Erwartete Elemente sind
> <{http://cxf.apache.org/bindings/corba/idl/repro}id>,<{http://cxf.apache.org/bindings/corba/idl/repro}s1>
>
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:808)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:629)
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:157)
> at
> org.apache.cxf.interceptor.BareInInterceptor.handleMessage(BareInInterceptor.java:138)
> ...
> {code}
> (sorry for german).
> Using a pure CORBA-client works.
> I will attach a repro project to this issue if I have figured out how it
> works :-)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
