Hi Fred, I see this code was taken from the EncryptedKeyProcessor, so presumably this > processor needs to be changed, as well. Even better, let's put these > processors under a common base, and define the common operation there. >
Exactly. There is a huge code duplication in those two processors and ideally they should have a common base. But i thought this is not the best time to do the refactoring as we are only 1 or 2 weeks away from the release. Maybe this is the more reliable operation to use: > > http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#isEqualNode(org.w3c.dom.Node)<http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#isEqualNode%28org.w3c.dom.Node%29> > According the documentation "This method tests for equality of nodes, not sameness (i.e., whether the two nodes are references to the same object) which can be tested with Node.isSameNode()" , So IMHO what we want to check is isSameNode instead of isEqualNode. WDYT ? Next question: Is this blocking for you, and did it show up in RC1 testing? > If we do fix it for 1.5.4, I suppose we can fix it on the 1_5_4 branch, and > then merge to trunk after the release. > Yep, this a blocker for Rampart. Anyway it seems that this code has been there since 3/25/07 but now only it causes a problem as we are actually using these results for encryption validation recently. So shall I commit this to both the branch and the trunk ? > PS> RC1 testing against CXF is going okay, though I've had to make some > slight modifications to the POM to get things just right. I'd like to do an > RC2 (with the BouncyCastle changes, as well), if folks are open to that. > Yes, That will be great. Testing against Rampart/Axis2 also going okay (except for this issue). regards, nandana
