> It's little strange but it's also true that it is good for testing. Can
> you post the stacktrace so i can take a look and see if there is something
> we can do about it?
Sure, it's pasted below, minus some Eclipse junk. The crash is in the
Manifest.verifyReferences method when it checks the size of the references
array. That array is null, unless you parse the SignedInfo from text into a
DOM. It doesn't get initialized when the signature objects are built during
signing. This is the general issue across the code, it doesn't maintain a
two-way sync between the state of the objects and the DOM fragments so that
you can operate in either "realm" consistently.
While I'm mentioning this, I also noticed a change in the exception
declaration of the XMLSignature element-based constructor. This required me
to make a code change, because the 1.1 library was declared as throwing an
IOException, which I had to catch, and now it complains that there is no
such exception thrown. I don't know if this is a great idea since it breaks
existing applications without a lot of reason that I can see...
-- Scott
java.lang.NullPointerException
at
org.apache.xml.security.signature.Manifest.verifyReferences(Manifest.java:29
0)
at
org.apache.xml.security.signature.SignedInfo.verify(SignedInfo.java:223)
at
org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignat
ure.java:591)
at org.opensaml.SAMLSignedObject.verify(SAMLSignedObject.java:323)
at
org.opensaml.SignatureTest$theTest.testSignature(SignatureTest.java:78)
at
org.opensaml.SignatureTest$theTest.access$0(SignatureTest.java:69)
at
org.opensaml.SignatureTest.testSignatureLoop(SignatureTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
