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
