DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16418>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16418 No deserialization context after changing SOAPBody in handler [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Target Milestone|--- |post-1.1 ------- Additional Comments From [EMAIL PROTECTED] 2003-01-30 16:43 ------- This is going to take some serious effort to get working. :( The problem, as you surmise, is that when we deserialize a text stream into a SOAPEnvelope, we figure out whether to make the body element a generic SOAPBodyElement or an RPCElement, which contains some extra information about method name and contained parameters. RPCElement is an Axis-specific construct, and so when your handler replaces the body with a generic SOAPBodyElement/MessageElement, we lose the information that we had about the request. The solution here is likely to tease out the "method/parameter" information away from the message model itself, so that we can rebuild it from a SOAPBodyElement if necessary. Unfortunately, if we want to do this I expect that we'll end up sacrificing some performance. In any case, this won't be fixed for 1.1, but can be looked at afterwards. Thanks for the test and the bug report!
