Jacques-Olivier Goussard wrote:
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 ?)
you are right but local java binding makes it tricky so it is more like
of best practice than an enforced requirement for local java provider AFAIR.
alek
/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
--
The best way to predict the future is to invent it - Alan Kay
