axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul slade" <>
Subject Re: Custom Deserializer is not being used when a SOAP Header is present in message
Date Mon, 27 Mar 2006 03:56:08 GMT
In case anyone is interested I have determined the cause of this
issue.  The Handler I was using to validate a SOAP header was defined
at the Transport level (as opposed to within a particular service). 
The MessageContext object is in a different state when Handlers
defined at the Transport level are called when compared to Handlers
defined at the Service level.

By moving my Handler definition from the Transport level to the
Service level I was able to resolve the issue.   This is not ideal
since I really want to execute this Handler for each service
regardless of how the service is confgured.

I think if I put SOAPPart.getEnvelope() early on in my Handler invoke
method, I can ensure that the MessageContext is in the correct state
(since it forces the complete message to be parsed).  That is yet to
be tested.


On 3/24/06, paul slade <> wrote:
> I am running Axis 1.4 and using the MTOM support.
> I have an "echo" service that just takes a DataHandler as input and returns it.
> When I use this service when there is no SOAPHeader included in the
> message it works happily.  When I use the service AND execute a
> Handler that adds a SOAP Header Element (for WS-Security) then I get a
> SAX exception.
> I have tried to go through the code and basically what seems to be
> happening (in the case there is a SOAP Header) is that the
> OperationDesc for the method I am calling is null within the
> RPCHandler that is trying to parse the element (from the message) that
> is of type DataHandler.
> When the OperationDesc is null Axis does not use the appropriate
> Deserializer.  It uses SimpleDeserializer when it should use
> JAFDataHandlerDeserializer.  This results in the SAX exception because
> the SimpleDeserializer does not expect nested elements.
> I have attached the following:
> 1. good message and log file (good.txt).
> 2. bad message and log file (bad.txt)
> You will notice that the SOAP body is the same for both good and bad
> scenarios.  It seems that the appearence of the SOAP Header that is
> causing issues.
> Any help would really be appreciated.
> paul

View raw message