[
http://issues.apache.org/jira/browse/AXIS-2139?page=comments#action_12317784 ]
Steve Green commented on AXIS-2139:
-----------------------------------
Venkat, Dims,
A full test program with beans and digital signatures will take some work, but
I don't think it's really necessary to see the meachanics of the problem that I
am describing. Let me illustrate with an example.
Suppose you have web service A and web service B, each with 1 call. The return
value of the A service contains an xs:any which holds a signed token. The call
to B also has an xs:any where the token should be placed. In my example,
"token" is the xs:any and thus a MessageElement [] in the beans.
aReply reply = A.doit();
request = new bRequest();
request.setToken(reply.getToken());
B.doit(request);
For the sake of simplicity, let's assume that the token array is just a single
MessageElement. During serialization of the token, 1 of 2 possible paths are
taken:
1. If the MessageElement is "dirty", the element is serialized with
outputImpl(). That would be ok except for the fact that whitespace nodes were
thown away during deserialization. Whitespace is crucial for digsig. I
_think_ it is happening in SOAPHandler.addTextNode().
String s = StringUtils.strip(val.toString());
val.reset();
// we need to check the length of STRIPPED string
// to avoid appending ignorable white spaces as
// message elmenet's child.
// (SOAPHeader and others does not accept text children...
// but in SAAJ 1.2's DOM view, this could be incorrect.
// we need to keep the ignorable white spaces later)
if(s.length()>0){
try {
// add unstripped string as text child.
myElement.addTextNode(s);
} catch (SOAPException e) {
throw new SAXException(e);
}
}
2. The MessageElement is not dirty. The sax replay will be used for
serialization and everything is sent out as it was received.
My (perhaps flawed) conclusions:
o MessageElements being marked as dirty after dser is a bug, and for all
intesive purposes devalues the sax recorder completely.
o SOAPHandler throwing away whitespace text nodes is broken by design and
probably should be fixed a some point but is not a blocker.
> SAX recorder is dirty after deserialization
> -------------------------------------------
>
> Key: AXIS-2139
> URL: http://issues.apache.org/jira/browse/AXIS-2139
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: current (nightly)
> Reporter: Steve Green
> Assignee: Venkat Reddy
> Priority: Blocker
> Attachments: Test2139.java, test.java
>
> During parsing of a message, SAX events are stored in the recorder, and
> MessageElement objects are created. The insertion of the new MessageElements
> are setting _isDirty, and thus invalidating the recorder for serialization.
> In my particular case, this breaks digital signatures becuase the
> MessageElement DOM is incomplete (it's missing some whitespace text nodes).
> It seems to me that it doesn't make sense to dirty the recorder during
> recording itself. This problem seemed to be created at version 1.13 of
> NodeImpl.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
