cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Problems with String[] and List<String> in Java-First Service
Date Mon, 21 May 2007 14:31:36 GMT

Chris,

On Monday 21 May 2007 08:44, Christopher Moesel wrote:
> Ah... Ok.  That clears things up a lot.  So, for now, it sounds like
> the recommended approach for doc/lit wrapped is to use the java2wsdl
> tool at design time rather than at runtime.  That's good to know. 
> When I have a chance, I'll give it a shot and see how it works.

The other option would be to use RPC literal instead of Doc literal.   
When using RPC/lit, each part gets it's own Element in the SOAP message, 
so the the JAXB issue doesn't apply.

Dan



> Thanks for the insight,
> Chris
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, May 18, 2007 6:13 PM
> To: cxf-user@incubator.apache.org
> Subject: Re: Problems with String[] and List<String> in Java-First
> Service
>
>
> 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
> marshalling/unmarshalling.
>
> 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"
>   type="echoStringListResponse"/>
>   <xsd:complexType name="echoStringListResponse">
>    <xsd:sequence>
>      <xsd:element maxOccurs="unbounded" minOccurs="0" name="return"
>   type="xsd:string"/>
>    </xsd:sequence>
>  </xsd:complexType>
>
>
> When reading without the wrapper type, JAXB just reads one element at
> a time.  Thus, when you pass in something like:
> <arr:input>1</arr:input>
> <arr:input>2</arr:input>
> <arr:input>3</arr:input>
> 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.
>
> Dan
>
> 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.j
> >av 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="http://schemas.xmlsoap.org/soap/envelope/"
> > xmlns:mysvc="http://myco.com/svc">
> >   <soap:Body>
> >     <echoStringListResponse xmlns=" http://myco.com/svc">
> >       <ns3:return xmlns:ns3=" http://myco.com/svc"
> > xmlns:ns2="http://www.w3.org/2005/08/addressing/wsdl"
> > xmlns="http://myco.com/svc/types">
> >         <item xmlns=""
> > xmlns:ns4="http://avid.com/xena/types">hello1</item>
> >         <item xmlns=""
> > xmlns:ns4="http://avid.com/xena/types">hello2</item>
> >         <item xmlns=""
> > xmlns:ns4="http://avid.com/xena/types">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(DocLitera
> >lI nI nterceptor.java:219)
> >         at
> > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(Doc
> >Li te ralInInterceptor.java:121)
> > ...
> >
> > 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
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message