ここでも同じ問題。進化によるJVM内部のバグのようです。
私はそれを追跡しましたcom.sun.org.apache.xml.internal.security.utils.resolver.implementations.ResolverFragment
Java 7u21以前では:
91: // Element selectedElem = doc.getElementById(id);
92: selectedElem = IdResolver.getElementById(doc, id);
Java 7u25 では:
87: selectedElem = doc.getElementById(id);
//...
93: if (secureValidation) {
secureValidation
は、XML Sig 検証に関する Java 7u25 の進化 ( changelogを参照) を参照しているため、この進化に取り組んでいる間に何か他のものを壊した に違いありません。
DOM ドキュメント ツリー (XMLObject のフラグメント) にまだ存在しないノードを解決できるカスタムjavax.xml.crypto.URIDereferencer
を提供することで、この問題を回避しました。javax.xml.crypto.dom.DOMCryptoContext.setURIDereferencer(URIDereferencer)
現在、これを Oracle に報告しています。回答をバグ ID で更新します。
編集:Apache SVNでこれを見つけました
編集 2:このバグ レポートのおかげで、これは XML の "Id" 属性処理の進化であることがわかりました。
以前のバージョンの java/JSR-105/SANTUARIO は、使用される「Id」属性に対して非常に寛容でしたdocument.getElementById(...)
が、この新しいバージョンでは、XML を話すIDとして識別される属性が必要です。つまり、属性に「Id」または「ID」という名前を付けるだけでは不十分です。最終的には XSD/DTD スキーマ検証によって、ID としてマークする必要があります。
残念ながら、有効ではないため Java で解析できないスキーマに従っています。
同じ状況にある場合は、以下の私の解決策を参照してください。それ以外の場合、XML ドキュメントに有効なスキーマがある場合は、@sherb ソリューションhttps://stackoverflow.com/a/17437919/233906をご覧ください。
解決
幸いなことに、のようなメソッドを使用して属性を ID としてタグ付けElement.setIdAttributeNode(org.w3c.dom.Attr,boolean)
できます。
「Id」ノードdescendant-or-self::*/@Id
を取得するような小さな XPath と、小さな Java を組み合わせることで、問題を解決できます。Attr
((Element)attr.getOwnerElement()).setIdAttributeNode(attr,true)
ただし、注意してください: setIdAttributeXXX()
現在のドキュメントとノードに対してのみ有効です。//各 DOM ツリーの新しいノードで //clone
を実行する必要がある場合adopt
import
setIdAttributeXXX()