David Blevins wrote:

I'm trying to get a few things to work with the OpenEJB side of the Geronimo 
web services integration.  I've basically broken apart the RPCProvider so that 
I can do the SAAJ to Java object marshalling of the arguments inside an 
EJBInvocation object which travels through our interceptor stack.  The 
HandlerChainImpl is inside the container stack, which is why I can't let the 
RPCProvider do the marshalling as it likes to now.

Anyway, I am having a hard time getting changes to the SAAJ objects done in 
handlers to show up in the MessageContext after it's traveled through the 
chain.  When I go do demarshal the data in SAAJ to Java arguments, I seem to 
get the same old data, but in completely new instances of SOAPMessage, 
SOAPBody, et. all.

I saw this bug report which seems to hint at the same issue:

http://issues.apache.org/jira/browse/AXIS-1469

And an aparent fix:

http://issues.apache.org/jira/browse/AXIS-1960

What is the exact optimization that happens with ALLOW_FORM_OPTIMIZATION turned 
on and why would it need to be off in the handler chain?   Also, what was done 
in AXIS-1960 to fix the issue.  Note I am using the latest snaphshot of Axis, 
but our integration is pretty tight and we may not be running the code where 
the fix was done.
Hi David

The problem had showed up in the JAX-RPC Handler chain : the Handler was making some changes to the message, but theses changes never come to the endpoint (or caller if it is in response message). We notice that the Handlers were calling some log methods, writing down the SOAPMessage.

When the SOAPMessage was transformed to a String, the current form of the SOAPPart passed from "SOAPMessage" to "Optimized". The side effect of this form change is that, from this moment, the real message content is in the Optimized form, and all changes you can do in the Handler on the SOAPMessage (and all childs) is never used.

So, before executing the JAX-RPC HandlerChain, we set a MessageContext property (ALLOW_FORM_OPTIMIZATION) to FALSE, to avoid that form change (in fact, we lock the form), then the SOAPMessage form is always the current content of the message, and all message change is really applied to the Message.

After the chain is completely executed, we turn off this option.

Take a look at o.a.axis.handlers.HandlerChainImpl and search for pre/postInvoke methods. If you're not using this HandlerChainImpl class, you need to add yourself in the MessageContext this property (and get the SOAPMessage in order to be sure the current form is SOAPMessage)

Cheers
-- Guillaume

Thanks a million!

-David


Reply via email to