Hi Freeman, I've attached a zip to the bug report. The zip contains a maven2 project demonstrating the bugs. I did not implement a client, but something like soapUI is better for seeing these bugs anyway.
https://issues.apache.org/jira/browse/CXF-655 Thanks for your help! -Chris -----Original Message----- From: Freeman Fang [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 4:01 AM To: [email protected] Subject: Re: Problems with String[] and List<String> in Java-First Service Hi Chris, Yes, String[] as input/output paras both has problem if use Doc/Lit of code first way. I fill a jira to track it. https://issues.apache.org/jira/browse/CXF-655 And we will fix it asap. Would you please try code first with rpc/lit mode if input or return is String[] before we fix CXF-655 as work around, I just test it and it works. The sei class is package org.apache.cxf.jaxws.service; import java.util.List; import javax.jws.WebMethod; import javax.jws.WebService; import javax.jws.soap.SOAPBinding; @SOAPBinding(style = SOAPBinding.Style.RPC, use = SOAPBinding.Use.LITERAL) @WebService(name = "Hello", targetNamespace = "http://mynamespace.com/";) public interface SayHi { @WebMethod(operationName = "sayHi", exclude = false) String[] getStringArray(String[] string); } The impl class should be package org.apache.cxf.jaxws.service; import java.util.ArrayList; import java.util.List; import javax.jws.WebService; @WebService(serviceName = "SayHiService", portName = "HelloPort", targetNamespace = "http://mynamespace.com/";, endpointInterface = "org.apache.cxf.jaxws.service.SayHi") public class SayHiImpl implements SayHi { public String[] getStringArray(String[] strs) { String[] strings = new String[2]; strings[0] = "Hello" + strs[0]; strings[1] = "Bonjour" + strs[1]; return strings; } } Also, would you please provide the code you are testing? I mean the SEI, impl and mainline of server and client. Thanks very much Freeman 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.java: > 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(DocLiteralInI > nterceptor.java:219) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLite > 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 > >
