> the problem i think is with Integer[] -> int[] transformation
> - what to
> do when one element in Integer[] array is null?
Well, what happens in the case Integer/int ? You get a NPE ?
I guess we should really mimic this case.
> this will also have performance (checking if every element in
> array is
> null) and memory implications (creating copy of array),
Only if one mixes int[] and Integer[] in the same class,
and we can advise not to do it (but still implement it for
maximum interop).
> problem of pass-by-reference (what if Integer a[2], a[1] = a[0], amd
> inside java method one has a[0] = null - a[1] will be changed?) - but
> that would be ok if pass-by-value was always used.
Pass-by-value is the only way to present a common view
of a service regarless of the binding (no pass-by ref in SOAP
or am I mistaken ?)
/jog
> -----Original Message-----
> From: Aleksander Slominski [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 10, 2004 2:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: int[] and Integer[]
>
>
> Jacques-Olivier Goussard wrote:
>
> >>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.
> >
> the problem i think is with Integer[] -> int[] transformation
> - what to
> do when one element in Integer[] array is null?
>
> >Is there a gotcha I don't see ?
> >
> >
>
> this will also have performance (checking if every element in
> array is
> null) and memory implications (creating copy of array),
> finally there is
> problem of pass-by-reference (what if Integer a[2], a[1] = a[0], amd
> inside java method one has a[0] = null - a[1] will be changed?) - but
> that would be ok if pass-by-value was always used.
>
> alek
>
> > /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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
>
>
>
>
