You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by David Blevins <da...@visi.com> on 2005/06/09 09:46:18 UTC
SAAJ and Form optimization
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.
Thanks a million!
-David
Re: SAAJ and Form optimization
Posted by Davanum Srinivas <da...@gmail.com>.
David,
http://issues.apache.org/jira/browse/AXIS-1960 is because of a
setDirty flag not being set properly when the dom elements are
manipulated. Venkat will fix this soon. This has nothing to do with
the optimization flag.
thanks,
dims
On 6/9/05, Guillaume Sauthier <Gu...@objectweb.org> wrote:
> 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
> >
> >
> >
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: SAAJ and Form optimization
Posted by Venkat Reddy <vr...@gmail.com>.
hi David,
Both AXIS-1960 and AXIS-1469 are reopened and are expected to be fixed
for 1.2.1. My perspective is that those two bugs are related to the
issue of SOAPMessage.saveChanges() not working as expected. I have
seen that this is happening because the dirty flag is not being set to
true inside inside NodeImpl whenever changes are made, thus causing
the serialization of it to simply replay the SAX events. I'm in the
process of fixing these errors.
- venkat
On 6/9/05, Guillaume Sauthier <Gu...@objectweb.org> wrote:
> 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
> >
> >
> >
>
>
Re: SAAJ and Form optimization
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
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
>
>
>