Deserializing extended types in default namespace

From: Jerry Pisk <>
Date: Wed, 7 Dec 2005 14:01:13 -0800


I'm having a problem accessing a jax-rpc based web service using a
.Net client. It comes down to what's in the subject and is not really
related to the client used, it's just that .Net framework uses the
default namespace while jax-rpc client prefixes all its namespaces.
Everything works fine when I do not derive types using xsd:extension
so I am going to focus on only the relevant pieces.

Service WSDL snippet:

<?xml version="1.0" encoding="UTF-8"?>
            <xsd:complexType name="Shape" abstract="true" />
            <xsd:complexType name="Point">
                <xsd:complexContent mixed="false">
                    <xsd:extension base="tns:Shape">
            <!-- Other types defined here -->
    <!-- Messages, ports, bindings and service definitions -->

The only difference in the SOAP message that comes in is that .Net
puts the request message into a default namespace
(xmlns="") while jax-rpc client
uses prefixed namespace
(xmlns:ns0="") on the message
element and the xsi:type is set to "Point" or "ns0:Point"
respectively. When the namespace is prefixed everything works as
expected, when it's not I get the following exception:

unexpected element type: expected=, actual=Point
        at org.example.service.Shape__service__InterfaceSOAPSerializer.doDeserialize(
        at com.sun.xml.rpc.encoding.InterfaceSerializerBase.deserialize(
        at org.example.service.RequestMessage__map__LiteralSerializer.doDeserialize(
        at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDeserialize(
        at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize(
        at org.example.service.IService_Tie.deserialize_Method(
        at org.example.service.IService_Tie.readFirstBodyElement(
        at com.sun.xml.rpc.server.StreamingHandler.handle(
        at com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(
        at com.sun.xml.rpc.server.http.JAXRPCServlet.doPost(
        at javax.servlet.http.HttpServlet.service(
        at javax.servlet.http.HttpServlet.service(
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(
        at org.apache.catalina.core.StandardWrapperValve.invoke(
        at org.apache.catalina.core.StandardContextValve.invoke(
        at org.apache.catalina.core.StandardHostValve.invoke(
        at org.apache.catalina.valves.ErrorReportValve.invoke(
        at org.apache.catalina.valves.FastCommonAccessLogValve.invoke(
        at org.apache.catalina.core.StandardEngineValve.invoke(
        at org.apache.catalina.connector.CoyoteAdapter.service(
        at org.apache.coyote.http11.Http11Processor.process(
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(
        at org.apache.tomcat.util.threads.ThreadPool$

This exception comes from
but so far I wasn't able to trace why it's expecting a blank name when
the types are in the default namespace. Any ideas?

I have also tried to write a message handler to prefix the default
namespace but that didn't work even when it did make the message to
look identical to the one sent by a jax-rpc client with all the
namespaces prefixed and it managed to break the response (invalid
content type kind of an exception on the client) even though the
handler only overwrote handleRequest from

Any help would be appreciated, I can provide more information if I
missed something important.

Jerry Pisk