Thanks Dan. I added asm.jar to my classpath and it solved the problem of
passing List objects over the wire.
I was trying to debug the CXF-2.0.3 source code yesterday and this is what I
noticed. During invocation of one of the interceptor handlers, there is a
call to WrapperHelper.createWrapperHelper() which creates a wrapper for
every request. This is followed by a call to
WrapperHelper.$ReflectWrapperHelper.createWrapperObject(). While this
function has necessary code to handle List objects, this code snippet is
never reached because of the preceding IF statement:
----------------------------------------------------------------------------
Snippet (A)
if (setMethods[x] == null && fields[x] == null) {
continue;
}
// Some code
if (o instanceof List) {
// Handle list objects
}
----------------------------------------------------------------------------
As a result the list object is passed as NULL and therefore does not appear
in SOAP request message. The reasons for the IF condition to fail are:
1. setMethods[x] is NULL as there are no explicit setter methods defined for
List data types
2. fields[x] is NULL because in WrapperHelper.createWrapperHelper(), this
valus is not set. This in turn is because, in the following code snippet
el.name() has a default value for the List object (##default) but the
partName is the actual field name. If the generated stub has the name
attribute defined explicitly in @XmlElement annotation for List object, then
we wouldn't be having this problem.
----------------------------------------------------------------------------
Snippet (B)
if (el != null
&& partName.equals(el.name())) {
elField.setAccessible(true);
fields.add(elField);
} else {
fields.add(null);
}
----------------------------------------------------------------------------
I gave a cursory look at the code execution when asm.jar is included in
class path and I find that the
WrapperHelper.$ReflectWrapperHelper.createWrapperObject() call is never
made. I will be looking into it in more detail later tonight to figure out
the new execution sequence. asm.jar probably generates the actual code
instead of using reflection. But if we were to not include asm.jar and still
get it working then one of the following things need to be done.
1. @XmlElement annotation should have name attribute explicitly defined as
the field name itself in the Java stub code (This will be the responsibility
of WSDL2Java)
2. If not, then el.name() in snippet (B) should return correct name if the
value is "##default"
3. If we do not want to bother any of these, then we need an explicit setter
method for List data types
(I feel this will be a clean and simple solution. I may be wrong, because
there could be a good reason for not having setter for List. It will be
helpful to know why.)
4. The best solution (with none of the above changes required) is to
generate a nice wrapper for collection. Again responsibility of WSDL2Java.
In Doc/Lit we have wrappers for exceptions, why not extend it to collection?
Interestingly the RPC/Lit style does this. If we pass an Integer[] , it
creates IntArray wrapper, and for arrays of any user-defined object say
Foo[], it creates FooArray wrapper.
[4] will help us to differentiate between a NULL array and empty array. This
is very important. The application developer need not have to worry about
wrapping his arrays before sending it across. I hope that CXF incorporates
this feature in the future.
- Kannan
dkulp wrote:
>
>
> Kannan,
>
> Can you try with the latest 2.0.4 snapshot (deploying now). There was a
> bug in 2.0.3 where if you DIDN'T have the asm jar on the classpath and
> you DID use the wrapper types, it didn't handle the Lists's correctly.
> The fix was to add an asm 2.x or 3.x jar onto the classpath. In any
> case, that should be fixed in 2.0.4.
>
>
> Dan
>
>
> On Monday 31 December 2007, rkannan wrote:
>> 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]
>> >> http://www.jroller.com/gmazza/entry/using_amazon_web_services_with
>> >> (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] http://soabook.com/code.html, Look for file:
>> >> /chap05/customjava/etc/schemacompiler_withcomments/SimpleOrder.java
>> >> and see the comments at the very-near-end of the file.
>> >>
>> >> HTH,
>> >> Glen
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer, IONA
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
>
--
View this message in context:
http://www.nabble.com/Problem-sending-List-as-parameter-using-Wrapped-Doc-Lit-style-tp14534395p14627976.html
Sent from the cxf-user mailing list archive at Nabble.com.
