Okay, so what would the relative risk be of using "==" in lieu of
"equals"?
Let's remind ourselves of what the function in question is trying to
do -- to find the relative complement (A - B) of 2 collections of
Nodes, where A is the collection of nodes After decryption, and B is
the collection of nodes Before encryption.
So the question is, will the XMLSec xmlCipher.doFinal(doc,
encBodyData, content) operation have any other side-effects on the
input than doing some pointer surgery on the DOM tree?
I think we could probably assume (with a fat comment around it) that
the changes to the tree will be stretegic and surgical. Or at least
we can make the change on that assumption, and test accordingly.
So I think I'd propose we try a pointer comparison (==) and see how
well that works.
I agree that isSameNode may be the better choice (in a 1.5 scenario).
The equals comparison could prove costly.
Nanada, were you going to make this change on the 1_5_4 fixes branch?
Or did you want me to?
-Fred
On Apr 24, 2008, at 5:36 AM, O hEigeartaigh, Colm wrote:
Hi guys,
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 ?
Both are non-runners for this release, as neither isSameNode() or
isEqualNode() are available in JDK < 1.5.
Colm.
________________________________________
From: Nandana Mihindukulasooriya [mailto:[EMAIL PROTECTED]
Sent: 24 April 2008 05:28
To: Fred Dushin; wss4j-dev
Subject: Re: Error in the logic of retrieving decrypted nodes in the
reference list processor
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)
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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
