> i think if XML schema define ints to be non-nillabel it
> should be enough?
Sure, this is a workaround, but I would expect to be able to
generate my WSDL from my java class let say using AXIS tools
and then simply add the java binding to it, without having
to mess up with the schema.
> sounds like good idea in general though i am not sure how it
> should be
> translated to actual providers.
What's the problem ? When looking up methods, we have to
look up indifferently a int[] and a Integer[] and provide
straigthforward util routines to transform one into
another. Is there a gotcha I don't see ?
/jog
> -----Original Message-----
> From: Aleksander Slominski [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 09, 2004 11:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: int[] and Integer[]
>
>
> Jacques-Olivier Goussard wrote:
>
> >Hi
> >I encounter problems with int[] and Integer[] in the
> >java binding.
> >Those two are mapped to the same ArrayOf_xsd_int
> >schema type, which makes them undistinguishable from
> >the WSDL perspective. So how can one know if the
> >WSIFInputMessage should contain a int[] or a
> >Integer[], solely based upon the information given
> >in the WSDL ?
> >
> >
> i think if XML schema define ints to be non-nillabel it
> should be enough?
>
> >If there is a mismatch, WSIF complains rightly that it
> >cannot find a method with matching argument types.
> >
> >Of course, I could create different schema types
> >for each java type, and use the typemap embedded in
> >the java binding to decide whih operation takes
> >which type of object. But this will make my client
> >code dependent of the binding, which does not follow
> >the WSIF design.
> >
> >IMHO, this should be automatically handled by the
> >java provider. Indeed, int and Integer are already
> >interchangeable, thanks to the reflection API that
> >lets you call 'void foo(int)' with an Integer argument
> >(invoke takes an array of Objects as arg). So WSIF
> >should be augmented and extend this scheme to arrays.
> >Any thoughts on this ?
> >
> >
> sounds like good idea in general though i am not sure how it
> should be
> translated to actual providers.
>
> it is true that in case of Java Reflection all is Integer
> however there
> is metadata of Class (Integer.class or Integer.TYPE) to be able to
> distinguish between int and Integer for method signatures.
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
>
>
>
>
