You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by rkannan <rk...@yahoo.com> on 2007/12/29 03:49:29 UTC
Problem sending List as parameter using Wrapped Doc/Lit style
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).
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. As a result, the Integer
list that I send as parameter is not getting sent across the wire. I
verified this from the SOAP message request. When I added a setter method
manually to the stub class this problem got fixed. The stub class has a
comment that says that the accessor method returns a reference to live list
and hence there is no explicit setter method, but this works only when there
is a wrapper created for the List.
I am not sure if this is a known bug with CXF or I am missing something
fundamental. I am blocked on this for a day now. To avoid ambiguity, I am
giving the code snippet of SEI and implementation class with annotations.
******************************************************
@WebService(name = "CompanyServiceImplPortType")
@SOAPBinding(style = Style.DOCUMENT, use = Use.LITERAL)
public interface CompanyService {
public Integer[] foo(@WebParam(name = "ids") Integer[] ids);
}
******************************************************
@WebService(endpointInterface = "CompanyService")
public class CompanyServiceImpl {
public Integer[] foo(Integer[] ids) {
http://www.nabble.com/file/p14534395/Nabble.zip Nabble.zip
// Do something with ids. -----> Problem here: ids is always
null
return new Integer[] {new Integer(200), new Integer(2000)};
}
}
******************************************************
For ease of understanding, I am attaching the WSDL and the generated stub
classes.
CompanyServiceImplPortType.java is the service interface stub class
Foo.java is the request stub class
FooResponse.java is the response stub class
Thanks,
Kannan Rajah http://www.nabble.com/file/p14534395/Nabble.zip Nabble.zip
--
View this message in context: http://www.nabble.com/Problem-sending-List-as-parameter-using-Wrapped-Doc-Lit-style-tp14534395p14534395.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem sending List as parameter using Wrapped Doc/Lit style
Posted by rkannan <rk...@yahoo.com>.
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
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
>
>
>
>
--
View this message in context: http://www.nabble.com/Problem-sending-List-as-parameter-using-Wrapped-Doc-Lit-style-tp14534395p14561206.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf build from source - cant find maven-jaxb-plugin
Posted by Glen Mazza <gl...@verizon.net>.
Here are the pom.xml's I use:
http://www.jroller.com/gmazza/date/20071205
HTH,
Glen
Am Sonntag, den 30.12.2007, 22:42 -0500 schrieb Mike Lawrence:
> Anyone know how to resolve this problem?
>
>
> [INFO] Failed to resolve artifact.
>
> GroupId: com.sun.tools.xjc.maven2
> ArtifactId: maven-jaxb-plugin
> Version: 1.1.0
>
> Reason: Unable to download the artifact from any repository
>
> com.sun.tools.xjc.maven2:maven-jaxb-plugin:pom:1.1.0
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> java.net (http://download.java.net/maven/1/)
>
>
>
> I'm trying to build from source. I've had to change several parent version
> numbers in order to download the resources from the central repo:
>
> /parent/pom.xml:
>
> <jaxb.impl.version>2.1.4</jaxb.impl.version>
> <jaxb.xjc.version>2.1.4</jaxb.xjc.version>
>
>
> <groupId>com.sun.tools.xjc.maven2</groupId>
> <artifactId>maven-jaxb-plugin</artifactId>
> <version>1.1</version>
>
>
> Sincerely,
>
> Mike Lawrence
>
cxf build from source - cant find maven-jaxb-plugin
Posted by Mike Lawrence <mi...@systemsplanet.com>.
Anyone know how to resolve this problem?
[INFO] Failed to resolve artifact.
GroupId: com.sun.tools.xjc.maven2
ArtifactId: maven-jaxb-plugin
Version: 1.1.0
Reason: Unable to download the artifact from any repository
com.sun.tools.xjc.maven2:maven-jaxb-plugin:pom:1.1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
java.net (http://download.java.net/maven/1/)
I'm trying to build from source. I've had to change several parent version
numbers in order to download the resources from the central repo:
/parent/pom.xml:
<jaxb.impl.version>2.1.4</jaxb.impl.version>
<jaxb.xjc.version>2.1.4</jaxb.xjc.version>
<groupId>com.sun.tools.xjc.maven2</groupId>
<artifactId>maven-jaxb-plugin</artifactId>
<version>1.1</version>
Sincerely,
Mike Lawrence
Re: Problem sending List as parameter using Wrapped Doc/Lit style
Posted by Daniel Kulp <dk...@apache.org>.
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
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem sending List as parameter using Wrapped Doc/Lit style
Posted by rkannan <rk...@yahoo.com>.
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
> dkulp@apache.org
> 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.
Re: Problem sending List as parameter using Wrapped Doc/Lit style
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem sending List as parameter using Wrapped Doc/Lit style
Posted by rkannan <rk...@yahoo.com>.
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
>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Problem-sending-List-as-parameter-using-Wrapped-Doc-Lit-style-tp14534395p14561207.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem sending List as parameter using Wrapped Doc/Lit style
Posted by rkannan <rk...@yahoo.com>.
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
>
>
>
>
--
View this message in context: http://www.nabble.com/Problem-sending-List-as-parameter-using-Wrapped-Doc-Lit-style-tp14534395p14555713.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem sending List as parameter using Wrapped Doc/Lit style
Posted by Glen Mazza <gl...@verizon.net>.
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