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 <[EMAIL PROTECTED]> 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/

Reply via email to