OK, it worked without doing anything special for the array.
The extra classes are included in the wsdd and it works, but if a Bean[] appears explicitly as an argument of a method there's also an explictit type mapping in the wsdd for the Bean[], but not when using --extraClasses. It works, but I am curios why the difference.
Thanks for your tip.
Tim
Sebastien Mayemba Mbokoso wrote:
I think u don't need to include anything special for your arrays. Generate all your stubs with the task WSDL2Java and look at in the deploy.wsdd if the extra classes are mapped.
------------- Sebastien
On Wed, 16 Feb 2005 12:12:53 -0800, Tim K. (Gmane) <[EMAIL PROTECTED]> wrote:
Yes, I do. Ah, I missed the --extraClasses option ...
Do I need to also include anything special for the arrays to work (e.g.a B[] in addition to B)?
Thanks.
Tim
Sebastien Mayemba Mbokoso wrote:
Do you know all the object types of 'Object o' at run-time ? If you do maybe you can use Java2WSDL with that more option : --extraClasses ?
----------- Sebastien
On Wed, 16 Feb 2005 11:20:24 -0800, Tim K. (Gmane) <[EMAIL PROTECTED]> wrote:
Hello,
Using java2wsdl to generate the WSDL from java server side classes, how can I force the registration of a serializer/deserializer for a bean that does not appear directly in the method arguments, e.g.:
public A foo(A a)
where A is a bean which can contain another bean B and also a bean array B[] but it's not typed (e.g. it's defined as an Object):
A { ... Object o; // At run-time this can be B, B[] or other things. ... }
The problem is that at run-time the server complains that there is no deserializer for B which makes sense because java2wsdl has never seen B anywhere in the method signatures.
The work-around so far has been to add a dummy method that has both B and B[] as arguments, but there's gotta be a nicer way to do it.
Thank you for your help.
-- Tim
