Kannan,
The fix for the lists is pretty much exactly what you discovered: the if
before the "o instanceof List" should be after the instanceof List.
That fix is in place for 2.0.4 so when that is released (couple weeks),
that will work.
If ASM is found, we do generate a special class that handles pulling the
parts out instead of using reflection. It's a little quicker and can be
jit optimized. The generated class doesn't have the same bug. Only
the reflection form does.
To address issues [3] and [4]....
[3] This is per jaxb spec. For collections, the jaxb spec specifically
just provides a getter, no setter. More importantly, we HAVE to have
this working with no setter in order to pass the JAX-WS TCK. Part of
the TCK is to use applications created with the RI implementation
(Metro) running in CXF and the RI doesn't generate the setters either
(again, as per jaxb spec).
[4] Again, this is per jaxb spec. We probably could create a config
option someplace to control this, but the default needs to be as the
current behavior in order for the TCK to pass.
There's a bunch of little things that we have to do due to JAX-WS
compatibility. Another example is making the schemas to have
elementForm=unqualified. I'd greatly prefer qualified, but the tck is
important.
Dan
On Friday 04 January 2008, rkannan wrote:
> 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_wi
> >> >>th (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.j
> >> >>ava 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
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
