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:[EMAIL PROTECTED] > Sent: Friday, May 18, 2007 6:13 PM > To: [email protected] > 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 [EMAIL PROTECTED] http://www.dankulp.com/blog
