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.
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.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="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(DocLiteralI >nI nterceptor.java:219) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLi >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
