Nullable primitives from Java webservice received as null in .Net
Niall
dotnet.framework on May 16 at
(http://groups.google.com/group/microsoft.public.dotnet.framework/browse_thread/thread/c1dd4f0a021a0e71/1ae86cd754c7b7d2?lnk=st&q=&rnum=3&hl=en&utoken=2KAcT0QAAACAT_kPml7nPanGq5_khmjXM3lTuJUrpchkk4PfyJ8QBJNg0tGVFuqI3uPOVaXa-mNYEzHwTZsVie9Lz8ynrMUKZDW0biiNx_26ZoVcD0w9aA).
Steven Cheng from MS was involved in the discussion, but it didn't seem that
there was a resolution on the group.
We have a Java web service which is using Java objects for the equivalent
primitives so they can be null (ie: java.lang.Integer, Boolean, etc). What we
find is that the first instance of each unique value for the field will be
received correctly by our .Net client. However, subsequent values are
received as null, even when values are actually specified. Here is a snippet
of the xml received by the client which shows the problem:
<schonbucherParams i:type="wn11:SchonbucherParamsView">
<bucketLength i:type="d:int" n1:id="6">100</bucketLength>
<integrationNumberOfSteps n1:ref="6" />
</schonbucherParams>
Both values should be received as 100. However, bucketLength is received as
100, while integrationNumberOfSteps is received as null. It looks as if the
second value is making a reference to the first instance of "100" through
n1:ref="6", but the reference is not being followed by the .Net client, so it
sees no value and gives it null.
The WSDL for integrationNumberOfSteps is:
<xsd:element name="integrationNumberOfSteps" nillable="true" type="xsd:int" />
It seems to me that the .Net client is seeing "xsd:int" as the type and
treating it as a primitive, and therefore not following the references.
Does anyone have any suggestions for ways to fix this problem? We have
little to no control over the WSDL and soap implementation of the server.
We're use WSE 3.0 on the client. The only option we can think of is making
our own wrapper classes for the primitive types so that they will be
serialized as objects without being recognised as having an underlying
primitive type.
Thanks,
Niall
Steven Cheng[MSFT]
Yes, there does existing some existing thread discussing on the similar
issues in the newsgroup. I remember the issue you refered is related to a
custmo value object's boolean member, and we haven' been able to get
progress in that thread. For your scenario, I've got that you're just
sending some primitive values as web method's parameters. I think your
analysis below is reasonable
================
It seems to me that the .Net client is seeing "xsd:int" as the type and
treating it as a primitive, and therefore not following the references.
================
Actually, such problems mostly occurs when the webservice is defined as
"Rpc/Encoded" format instead of "Document/Literal", rpc/encoded style SOAP
message is likely causing interop issues since the client ans server are
difficult to followup a consistent SOAP message format(through XSD schema).
Since you're using .net 2.0(WSE 3.0), have you tried manually modify the
.net client proxy code and change the parameter object's type to Nullable
types in .net 2.0? This can help wrapper a primitive type in .net as a
reference type(without using a wrapper class).
#Nullable Class
http://msdn2.microsoft.com/en-us/library/fs5xdbk8.aspx
Also, I'm wondering whether it is convenient that you provide me a publich
accessible service endpoint address (demonstrate your current java
service). If so, I'd like to perform some local tests against it.
Please let me know if you have any other concerns.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Niall
We use the WSDL tool to generate the webservice proxy, and out of the box,
it's generating the nullable types (int? in this case). So there aren't any
issues when dealing with actual nulls when they occur.
I've talked with our Java server guys and apparently we're stuck with
RCP/encoded, as we have quite complex and large object graphs in the data
that we send, including bidirectional relationships (ie parent <=> child).
The size of the SOAP messages are already a performance issue for us
(surprise surprise), so any extra data in the messages would unfortunately
only make it worse, even if we did manage to avoid the bidirectional
relationships.
As for publishing the service, unfortunately I don't think that can happen.
I work at a bank, so I'm a long way behind a firewall and don't have the
privileges to make any services public.
Thanks for your help so far. It's looking like our best/only option is to
creata small wrapper classes around the nullable primitives that we use, and
provide implicit conversions on the .Net side. It could be worse.
Niall
Steven Cheng[MSFT]
Yes, I can understand your decision since RPC/encoded does has performance
advantage since it act much more like the binary programming model(which
can use reference to avoid duplicated data).
Anyway, I also agree that using a wrapper should be the reasonable solution
for this case. If there is anything else we can help later, please feel
free to post here.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
Niall
using C# services as well as client (or Java server, Java client, but then I
wouldn't have a job). Unfortunately that's not my decision :(
Niall
Steven Cheng[MSFT]
Good luck!