[jira] Resolved: (CXF-655) String[] cann't be input paras or return value when use doc/lit of code first way

["Daniel Kulp (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-655.
-----------------------------

    Resolution: Fixed


Finally fixed in svn revision 557406


> 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
>            Assignee: Daniel Kulp
>             Fix For: 2.0.1
>
>         Attachments: arrays_example_service.zip
>
>
> 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://myco.com/svc/types">hello1</item>
>         <item xmlns=""
> xmlns:ns4="http://myco.com/svc/types">hello2</item>
>         <item xmlns=""
> xmlns:ns4="http://myco.com/svc/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.