cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Problems with String[] and List<String> in Java-First Service
Date Fri, 18 May 2007 22:12:55 GMT

Chris,  (and Freeman)

This problem is exactly why the RI implementation requires you to run 
wsgen on the "Java first" cases.   For wrapped doc/lit, that generates 
the wrapper types which the runtime can use to handle the 

Without having the generated wrapper types, marshalling/unmarshalling 
becomes a LOT more complex unless we completely change the generated 
schema, but then we'll be in violation of the mapping sections of the 
JAX-WS spec.   Basically, the schema we want is:
<xsd:element name="echoStringListResponse"
  <xsd:complexType name="echoStringListResponse">
     <xsd:element maxOccurs="unbounded" minOccurs="0" name="return"

When reading without the wrapper type, JAXB just reads one element at a 
time.  Thus, when you pass in something like:
to unmarshal with String[] as the type, you actually get back a 
String[0].  It doesn't read anything as jaxb is actually looking for 
the "other" type that you saw generated in your schema.   (the "item" 
element names) 

The only option we really have is to "manually" read one element at a 
time (checking for the qname and such) and building up the List or [] 
ourselves.   Same goes for writing.  We have to loop through the 
array/list and write each out individually.   

The work Freeman did doesn't solve the problem as it still cannot read 
the correct messages.    It also changed the generated wsdl such that 
it's not compatible with the spec.   Thus, we're going to have to back 
that out.   I've started poking around a bit in the code to see what 
will need to be done to get this working in the case where wrapper types 
are not generated, but it's not going to be a quick/easy fix.   

Btw: with the older code (before Freeman's changes), if you would have 
run j->w and had it generate the wrappers and stuff, it probably would 
have worked. 


On Tuesday 15 May 2007 14:15, Christopher Moesel wrote:
> I've been experimenting with Java-first services (for a friend ;) and
> have run into some issues.  I am using the latest version off svn HEAD
> (the RC has its own set of issues w/ Java-first services).  I can
> break it in several different and interesting ways.
> (1) It appears that I cannot have a string array (String[]) as a
> return object for a @WebMethod.  If I try, I get the following
> stacktrace (just beginning of it):
> org.apache.cxf.interceptor.Fault: Marshalling Error:
> [Ljava.lang.String; is not known to this context
>         at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.jav
>a: 149)
> ...
> (2) If I try to use a List<String> as the return object instead, then
> there is no exception/fault, but the response does not validate
> against the schema.  It adds the following complexType to the WSDL:
> <xs:complexType final="#all" name="stringArray">
>   <xs:sequence>
>     <xs:element maxOccurs="unbounded" minOccurs="0" name="item"
> nillable="true" type="xs:string"/>
>   </xs:sequence>
> </xs:complexType>
> But that context type is not referred to in the WSDL, as the response
> wrapper is still defined like so:
> <xsd:element name="echoStringListResponse"
> type="echoStringListResponse"/>
> <xsd:complexType name="echoStringListResponse">
>   <xsd:sequence>
>     <xsd:element maxOccurs="unbounded" minOccurs="0" name="return"
> type="xsd:string"/>
>   </xsd:sequence>
> </xsd:complexType>
> But an actual response from the service looks like this:
> <soap:Envelope xmlns:soap=""
> xmlns:mysvc="">
>   <soap:Body>
>     <echoStringListResponse xmlns="">
>       <ns3:return xmlns:ns3=""
> xmlns:ns2=""
> xmlns="">
>         <item xmlns=""
> xmlns:ns4="">hello1</item>
>         <item xmlns=""
> xmlns:ns4="">hello2</item>
>         <item xmlns=""
> xmlns:ns4="">hello3</item>
>       </ns3:return>
>     </echoStringListResponse>
>   </soap:Body>
> </soap:Envelope>
> As you can probably see, there are a number of things wrong above:
> - treats ns3:return like a stringArray type not unbounded xsd:string
> - sets the namespace of the item elements to ""
> - lots of redundant and unneeded namespace declarations
> (3) If I have a service with one operation that returns String[] (like
> #1 above) and one that returns List<String> (like #2 above), then #1
> ceases to fail in the way it had before.  Instead of throwing an
> exception (as in #1), it now fails the same way #2 does-- by returning
> a response that is invalid against the schema (and looks like the
> stringArray complex type that mysteriously appeared in the WSDL).
> (4) Lastly, if an operation has a String array (String[]) as an input
> parameter, then you get the following stack trace (beginning only):
> java.lang.ClassCastException: java.lang.Class
>         at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(DocLiteralI
>         at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLi
> ...
> For those of you who are now wondering, incidentally, using a
> List<String> as an input parameter does seem to work correctly (aside
> from unneeded namespace declarations).  So this particular problem is
> only for String[].
> Although I want to convince my friend to use WSDL-first anyway, I'd
> rather that the argument NOT be "CXF can't do java-first right, so you
> have to use WSDL-first".  Because then they might use .NET.  Yikes.
> Anyone know of any workarounds or know of something I might be doing
> wrong?
> -Chris

J. Daniel Kulp
Principal Engineer
P: 781-902-8727    C: 508-380-7194

View raw message