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