>> When I start all my unit tests I get many (8) exceptions that all relate
> to
>> the same problem. What I do generally is to register a new XPath function
>> (the here() function as defined in XML Signature) and then I apply some
>> XPathes using that function.
>
> How complicated is that function? If it's short, pass it along and we can
> do a quick check to see if it's doing anything unreasonable...
Well, the function itself is relatively simple [1] but I think my errors
are in the usage of that function. The code that throws these exceptions
can be found in [4,5]. In [6] I could 'solve' the problem by looking
whether the Node I want to inspect is of class
if (node.getClass().getName().equals(
"org.apache.xml.dtm.ref.dom2dtm.DOM2DTM$defaultNamespaceDeclarationNode"
)) {
// skip processing;
}
but I think this nasty patch is not what you xalan developers expect in
production code. In [4,5] my code crashes when I do things like
org.apache.xpath.NodeSetDTM dtmIterator =
new org.apache.xpath.NodeSetDTM(inputNodes, xPathContext);
but I think it would be easier for you to have a look on the source code
directly rather than listening to my obfuscated explanations ;-) I think
the most probable solution would be if I see whether a fixed bug 4336 [0]
would make all other things go right.
>> java.lang.RuntimeException: Could not resolve the node to a handle
>
> Generally what that means is that you've passed us a DOM node which is
> _not_ part of our DTM model -- or which is not registered into this
> particular DTM manager -- at a place where we expected the node to be one
> of ours. You can think of it as a type-cast failure, though it's actually
> implemented as a table lookup.
>
> So the question is where this node came from, what you're asking us to do
> with it, and whether that operation actually makes sense or not.
I understand that this exception is thrown by supplying Nodes which do not
belong to that document. But I only supply nodes that I originally
retrieved from the corresponding document. The problem itself is related to
that "xmlns:xml" attribute we talked about yesterday.
Christian
[0] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4336
[1] http://www.w3.org/TR/xmldsig-core/#function-here
[2]
http://cvs.apache.org/viewcvs.cgi/xml-security/src/org/apache/xml/security/
transforms/implementations/FuncHere.java
[3]
http://cvs.apache.org/viewcvs.cgi/xml-security/src/org/apache/xml/security/
transforms/implementations/FuncHereContext.java
[4]
http://cvs.apache.org/viewcvs.cgi/xml-security/src/org/apache/xml/security/
transforms/implementations/TransformXPath.java
[5]
http://cvs.apache.org/viewcvs.cgi/xml-security/src/org/apache/xml/security/
transforms/implementations/TransformEnvelopedSignature.java
[6]
http://cvs.apache.org/viewcvs.cgi/xml-security/src/org/apache/xml/security/
transforms/implementations/TransformBase64Decode.java
