cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <j...@apache.org>
Subject [jira] Created: (CXF-655) String[] cann't be input paras or return value when use doc/lit of code first way
Date Wed, 16 May 2007 07:57:16 GMT
String[] cann't be input paras or return value when use doc/lit of code first way
---------------------------------------------------------------------------------

                 Key: CXF-655
                 URL: https://issues.apache.org/jira/browse/CXF-655
             Project: CXF
          Issue Type: Bug
            Reporter: Freeman Fang


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? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message