Hi Mauro,
Thanks for your reply. I did signed up for the list a little late so I
thought I was missing something.
The point which got me worried in the first place was your comment that
with the current fix
"Axis2 client wouldn't be able to specify "null" as input parameter and
won't be able to handle null as an output parameter!"
Now if this is this the case then I do not understand why we need a fix
which solves some old .NET bugs but makes usage of the Axis2 client
somewhat uncomfortable (you did mention that null can be passed using
Integer.MIN_VALUE which I also find more than ugly). After all, for .NET
or other specific client we do have the contract-first approach as you
have mentioned.
Mike
Mauro Molinari wrote:
Michail Prusakov ha scritto:
I am sorry I've missed the discussion, but why have you made
minOccurs=1 for null non-primitives? As far as I see it, if a value is
null the wsdl should allow passing it as nill or not passing it at all
because:
1) two ways of saying something is null means better interoperability
as if a client does not support one way, it can use the other. I
believe .NET 1.x clients are good example of this.
2) by omitting a value we can make the soap message smaller and thus
increase performance.
Hi Mike,
if you read the whole discussion and especially the related issue(*),
you'll see that by specifying minOccurs=0 for null non-primitives will
cause Axis2 to generate a WSDL from which .NET tools will have problems
to generate clients. These are .NET bugs, but if they can be avoided
it's better, otherwise .NET interoperability is severely affected.
IMHO the preferred way to solve this would have been to have a flag
(false by default) to use a ".NET friendly" generation algorithm, but
Amila preferred not to go this way.
(*) https://issues.apache.org/jira/browse/AXIS2-3300
