.NET not specifying namespace in web reply, but Java/Axis needs it

[PaulG]

Greetings,

[In a nutshell, the Java client is throwing an exception because it
doesn't expect the returned type it sees, because the namespace isn't
specified when the .NET side responds.]

I'm trying to get web services running, with C#/.NET on the server and
Java/Axis on the client. I managed to get a remote object returned,
but now that I've created a derived class from the original base, I'm
experiencing problems on the Java side.

I've got a base class Task, and an inherited class SpecialTask, which
I've derived from Task, on the .NET side. GetTask is a web method of
TaskManager, which returns Task, although in my code right now, it's a
SpecialTask that I'm actually returning.

An [XmlInclude(typeof(SpecialTask))] at the top of my GetTask method
in the TaskManger causes a description of SpecialTask to be inserted
into the generated wsdl. It looks right to me.

I created my Java stubs with:

wscompile.bat -f:searchschema -keep -gen config.xml (config.xml
contains reference to the wsdl)

However, when I call from Java, the response I get back contains:

....<GetTaskResponse xmlns="blah"><GetTaskResult
xsi:type="SpecialTask">
...
</GetTaskResult></GetTaskResponse>...

The actual exception the Java side throws starts with:

java.rmi.RemoteException: Runtime exception; nested exception is:
unexpected element type: expected=, actual=SpecialTask

and from fiddling with the source in the generated stubs, I see that
the Java side isn't working because it's looking for
{mynamespace}SpecialTask (not "" as it claims), but getting
{}SpecialTask which doesn't match. The Java side doesn't see the type
as belonging to any namespace when it reads the response, and I
haven't found a way yet on either side to make changes to compensate
for the other.

Paul

 

[PaulG]

I'm assuming the .NET Web Service an .ASMX web service, and

Yes, that is correct.

[SoapDocumentMethodAttribute( ResponseNamespace=
"{mynamespace}")]
[WebMethod]
public SpecialTask GetTask( )

I gave this a shot (no success, read on). Both with the response
namespace as "blah" and then again (as listed) as "blahresponse", just
to see the difference.

First, above my class declaration for the TaskManager, I have:

[WebService(Namespace="blah")]

At the moment, this is my GetTask method:

[WebMethod]
[XmlInclude(typeof(SpecialTask))]
[SoapInclude(typeof(SpecialTask))]
[SoapDocumentMethodAttribute(ResponseNamespace="blahresponse")]
public Task GetTask()
{
Task oTask = new SpecialTask();
return oTask;
}

I've also got my task classes as such:

[Serializable]
[XmlRoot(Namespace="blahresponse")]
public class Task
{
...
}

[Serializable]
[XmlRoot(Namespace="blahresponse")]
public class SpecialTask : Task
{
...
}

The returned data from the SOAP call contains:

....<GetTaskResponse xmlns="blahresponse">
<GetTaskResult xsi:type="SpecialTask">
...
</GetTaskResult>
</GetTaskResponse>...

However, the Java client still sees the response as not having a
namespace.

java.rmi.RemoteException: Runtime exception; nested exception is:
unexpected element type: expected=, actual=SpecialTask
....

This message is actually misleading, because from examining the source
for the deserializing Java code (if anyone is more familiar with the
internals here), these are the values of the variables in play:

name = "{blahresponse}GetTaskResult"
elementType = "SpecialTask"
ns1_mySpecialTask_LiteralSerializer.getXmlType() =
"{blahresponse}SpecialTask"

Basically, in the deserializer, if:

elementType.equals(ns1_mySpecialTask_LiteralSerializer.getXmlType())

was true, then an attempt to deserialize a SpecialTask would be made.
But they are not equal, because the namespace of the element read from
the response is missing. It's not that it's the wrong namespace, it's
that no matter what I do on the .NET side, the namespace isn't seen.

My guess is, there is still either a property somewhere that needs to
be set to make this work... or it is a bug or incompatibility in Axis.
But it's hard to believe I'm the first to find this if it's a bug.

Paul