cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rkannan <>
Subject Re: Problem sending List as parameter using Wrapped Doc/Lit style
Date Mon, 31 Dec 2007 19:22:04 GMT

I did some debugging of the generated stub code and this is what I found out.
When we are using Doc/Lit style, WSDL does not have array wrappers,
WSDl2Java generates stubs without the explicit setter method for Lists. Now,
when a service is invoked, a dynamic proxy is created that creates request
object and calls appropriate service method. This proxy is setting all
parameters correctly except List. I would expect the proxy to do the
following: Create a request object, retrieve the live List instance using
the getter, use the List parameter I have passed to populate this live list
and then send it across the wire. This is not happening, only a NULL list is
sent across. When I added an explicit setter method for the List it was
working properly.

Unless I am missing something here, it looks like a bug in the dynamically
generated proxy. Has anyone else faced this problem?

- Kannan Rajah 

rkannan wrote:
> Thanks for your reply. I will look into Metro today. Regarding the absence
> of setter method for List, the example that you had quoted is something
> that I had mentioned in my original post. I understand that a reference to
> the live list is returned, so we don't need an explicit setter method. But
> my point is this: 
> When there there are no wrappers for the List object, in my example, the
> generated stub has a method foo which takes a List as argument. This means
> that I have to create a List and send it as parameter. Since there are no
> setters, the List object is not set. I don't see a way to achieve this
> without a setter. Suppose there was a wrapper to the List object, then the
> argument to method foo will be this wrapper object. I will create the
> wrapper object, get the live list associated with it, populate it and send
> it as parameter. Clearly, here I do not need the setter for List.
> Everything will work fine in this case.
> I feel that when no array wrappers are created, there is a bug in the java
> code generation by wsdl2java.  The more serious concern here is that the
> WSDL does not have array wrappers. Is this a known issue with CXF? If so,
> it is going to be a big problem pursuing CXF, because the Doc/Lit style
> does not generate array wrappers, but allows passing NULL as top level
> parts; the RPC on the other hand, generates array wrappers, but does not
> allow passing NULL as top level parts. We want array wrappers and ability
> to pass NULL as parameters. This leaves us in a pickle.    
> Thanks,
> Kannan Rajah
> Glen Mazza-2 wrote:
>> Am Freitag, den 28.12.2007, 18:49 -0800 schrieb rkannan:
>>> I have a simple service method <foo> that takes an Integer array and
>>> returns
>>> an Integer array. I am using Wrapped Doc/Lit style, with JAX-WS and
>>> JAXB.
>>> The generated WSDL does not contain any wrapper for the array type (RPC
>>> style generates wrapper like IntArray, StringArray but Doc/Lit does
>>> not).
>> The JAXB artifacts are the same for CXF and Metro, because we use the
>> sample JAXB implementation.  The JAX-WS artifacts, however, might be
>> slightly different (although I think Metro does the same for what you
>> are saying.)  It might be best to create your objects using Metro[1] to
>> see if there is a difference.
>> [1]
>> (Step #5)
>> Note there is an <jaxws:enableWrapperStyle/> option described in Step #4
>> of [1], I think it is presently not working in CXF but does work with
>> Metro if that would help you.  (I believe you can use the CXF libraries
>> with Metro-generated client stubs/service skeletons.)
>>> This is an issue as it will lead to problems in differentiating between
>>> null
>>> and empty arrays. So how do I get wrappers automatically created for
>>> array
>>> types in my WSDL while using Doc/Lit style?
>>> I went ahead with this WSDL and generated the stub classes. I found that
>>> there is no setter method defined for List types. 
>> I think that is by design.  Example 5-4 from the source code download
>> from "SOA Using Java Web Services" (Hansen)[2] I think will explain the
>> situation to you.
>> [2], Look for file:
>> /chap05/customjava/etc/schemacompiler_withcomments/ and
>> see the comments at the very-near-end of the file.
>> HTH,
>> Glen

View this message in context:
Sent from the cxf-user mailing list archive at

View raw message