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 <[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 > > > > > > > >
