axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Melgar" <>
Subject RE: Namespace prefix mangling problem
Date Fri, 10 Aug 2001 17:26:53 GMT
Glen, That fixed it, thanks. That seems to bring up the question again
about who keeps track of information at the <Header> level since there is
no object that represents the <Header> element. Same for <Body>.

Now I've run into another problem with another handler.
On the client, the handler adds a mess of elements and sub elements within
the body of an RPC. The intent is that the corresponding handler on the
server side will remove these added elements before the RPC is actually
The problem occurs when the message is sent to the server, AxisServer tries
to convert it to a SOAPEnvelope to pick out the service name(?) to figure
out what chain to invoke, but DeserializationContext throws an exception
stating that it can't handle structured data.

Ideally, seems like AxisServer should pickout the information it needs from
the message, anything it can't understand should be remembered as a series
of SAX events. The message does not need to be completely deserialized
until the RPC is about to be invoked.

Here's the stack trace:
org.xml.sax.SAXException: Basic deser can't handle structured data!
        at org.apache.xerces.framework.XMLParser.parse(
        at javax.xml.parsers.SAXParser.parse(
        at org.apache.axis.Message.getAsSOAPEnvelope(
        at org.apache.axis.server.AxisServer.invoke(

David Melgar
Web Services Toolkit Development
Emerging Technologies

Glen Daniels <> on 08/10/2001 12:40:58 PM

Please respond to

To:   "''" <>
Subject:  RE: Namespace prefix mangling problem

> Regarding the namespace prefix mangling, I may have found the
> problem. I've
> been starting at this too long, still dont quite understand
> it, so my logic
> is likely to be faulty, but might help you folks.
> The events for startPrefixMapping occur before the element
> that contains
> them. In the case of the message I'm working with, SOAP-SEC prefix is
> defined within a <signature> element, but the event occurs before
> startElement(signature) event. This mean that the SOAP header object
> essentially needs to store the event.

Right - I just fixed this by marking the beginning of the recorded
SAX events for a MessageElement at the first prefix mapping, rather
than at the actual startElement.

> What I did as a fix, was change HeaderBuilder so that the
> SOAPHeader create
> occurs during HeaderBuilder.startElement. I don't understand
> the reasons
> its not normally done this way.

The reason is that the HeaderBuilder is reacting to the <SOAP-ENV:
Header> element.  Thus, the startElement() it receives is not for
each individual header, it's just the outer wrapper.  When the
headers inside <SOAP-ENV:Header> begin, that's when onStartChild()
gets called, and that's the right time to create the SOAPHeaders.
Doing it the way you have it will result in exactly one SOAPHeader
for any SOAP message with headers...

Let me know if my commit fixed your problem.


View raw message