<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi, <div class=""><br class=""></div><div class="">FYI, I solved it. </div><div class=""><br class=""></div><div class="">The idea is the following. Setting is wildfly 9, opensaml, 2.6, 3.x, java8. </div><div class=""><br class=""></div><div class="">In wildfly it is not so easy to predict which DocumentBuilderFactory is used, given the “redirect” mechanism. In fact, in <a href="https://github.com/jboss-modules/jboss-modules/blob/master/src/main/java/__redirected/__DocumentBuilderFactory.java" class="">https://github.com/jboss-modules/jboss-modules/blob/master/src/main/java/__redirected/__DocumentBuilderFactory.java</a>, it is stated a JAXP bug in the FactoryFinder, </div><div class="">which is exactly what I was facing. </div><div class=""><br class=""></div><div class="">On the other hand, when an Element is unmarshalled by xmltooling in the context above, it gets its DOM associated using the SAAJ. </div><div class="">Here, there is a funny thing: they overcome for whatever reason the FactoryFinder and they always instantiate the <a href="http://com.sun.org" class="">com.sun.org</a>.apache.xerces, </div><div class="">using a plain new(). </div><div class=""><br class=""></div><div class="">Results: when marshalling, the opensaml’s ParserPool gets the implementation from wildfly (the BasicParserPool uses the FactoryFinder)</div><div class="">but then, in the XMLHelper, in the adoptNode, the underlying implementation (which is xerces in wildfly, see here: <a href="https://developer.jboss.org/thread/272018" class="">https://developer.jboss.org/thread/272018</a>) returns null, and thus XMLHelper throws the “DOM Element Node Adoption Failed”. </div><div class=""><br class=""></div><div class="">Note that setting the builderfactory either in $JAVA_HOME/jre/lib/jaxp.properties, or in the -D in the wildfly JAVA_OPTS, does not work as expected, </div><div class="">as per the TCCL as above. </div><div class=""><br class=""></div><div class="">The workaround that I found is the following. The the Configuration.getParserPool().getBuilder().getDOMImplementation(), then get the DOM </div><div class="">implementation from the xmlObject.getDOM(), and check if they are the same. If not, take the DOM from the XML Object, create a new</div><div class="">DocumentBuilder out of the Configuration.getParserPool().getBuilder(), dump the xmlObject’s DOM to a byte array, parse it, and call the </div><div class="">xmlObject.setDOM(newDOM). Then marshall it. </div><div class=""><br class=""></div><div class="">HTH, </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Massi</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Il giorno 10 ago 2016, alle ore 18:02, Brent Putman <<a href="mailto:putmanb@georgetown.edu" class="">putmanb@georgetown.edu</a>> ha scritto:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class=""><p class=""><br class="">
    </p>
    <br class="">
    <div class="moz-cite-prefix">On 8/9/16 11:51 AM, Massimiliano Masi
      wrote:<br class="">
    </div>
    <blockquote cite="mid:11F3D334-D82D-42CF-A2CF-2740F57EF9DE@mascanc.net" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252" class="">
      Hi All, 
      <div class=""><br class="">
      </div>
      <div class="">I am running java 1.8 and wildfly 9. I have some
        issues with the DOM implementation, opensaml 2.6.1. </div>
      <div class=""><br class="">
      </div>
    </blockquote>
    <br class="">
    You know that OpenSAML 2.x is completely unsupported and EOL as of
    July 31, right?  But the problems/solutions here will be the same as
    for OpenSAML 3, so ...<br class="">
    <br class="">
    <br class="">
    <blockquote cite="mid:11F3D334-D82D-42CF-A2CF-2740F57EF9DE@mascanc.net" type="cite" class="">
      <div class="">My soap message is handled by saaj. When I get the
        SOAP header, and I unmarshall it, the DOM is </div>
      <div class=""><br class="">
      </div>
      <div class="">com.sun.xml.messaging.saaj.soap.impl.ElementImpl </div>
      <div class=""><br class="">
      </div>
    </blockquote>
    <br class="">
    I'm not personally familiar with SAAJ.  But I'm assuming that the
    way that you received the SOAP XML and parsed it to a DOM is not via
    our ParserPool, etc, but rather using some mechanism specific to
    SAAJ .  I suspect therein lies the problem (indirectly).
    <div class=""><br class="">
    </div>
    <br class="">
    <blockquote cite="mid:11F3D334-D82D-42CF-A2CF-2740F57EF9DE@mascanc.net" type="cite" class="">
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div class="">2016-08-09 17:46:38,515 INFO  [stdout] I got an
          exception. My implementation is: class
          org.apache.xerces.dom.NodeImplfrom:
<a class="moz-txt-link-freetext" href="jar:file:/opt/bin/jboss1/modules/system/layers/base/com/main/xercesImpl-debug.2.9.1.jar!/">jar:file:/opt/bin/jboss1/modules/system/layers/base/com/main/xercesImpl-debug.2.9.1.jar!/</a></div>
        <div class="">2016-08-09 17:46:38,515 INFO  [stdout] Their
          implementation is: class
          com.sun.xml.messaging.saaj.soap.impl.ElementImplfrom:
          vfs:/opt/conf/jboss1/deployments/mydep.ear/lib/saaj-impl.jar</div>
        <div class="">2016-08-09 17:46:38,515 ERROR [stderr]
          java.lang.ClassCastException:
          com.sun.xml.messaging.saaj.soap.impl.ElementImpl cannot be
          cast to org.apache.xerces.dom.NodeImpl</div>
        <div class="">2016-08-09 17:46:38,515 ERROR [stderr] <span class="Apple-tab-span" style="white-space:pre">    </span>at
org.apache.xerces.dom.CoreDocumentImpl.adoptNode(CoreDocumentImpl.java:1760)</div>
        <div class="">2016-08-09 17:46:38,515 ERROR [stderr] <span class="Apple-tab-span" style="white-space:pre">    </span>at
org.opensaml.xml.util.XMLHelper.adoptElement(XMLHelper.java:545)</div>
      </div>
      <br class="">
    </blockquote>
    <br class="">
    <br class="">
    It would seem that the root cause problem here is that the Apache
    Xerces DOM classes don't support adopting Nodes from a different DOM
    impl.  The message seems to imply that it's trying to
    unconditionally cast the passed-in to-be-adopted Node to a Xerces
    NodeImpl, and it's not.<br class="">
    <br class="">
    <blockquote cite="mid:11F3D334-D82D-42CF-A2CF-2740F57EF9DE@mascanc.net" type="cite" class="">
      <div class="">(</div>
      <div class=""><br class="">
      </div>
      <div class="">Now, I really don’t know how to proceed. Any hints
        on aligning the DOM implementations? Before, with java6 and </div>
      <div class="">jboss4, I was used to the endorsing mechanism, but
        in java8 + wildfly9 it does not seem to have any effect.</div>
    </blockquote>
    <br class="">
    I don't have any concrete ideas.  The OpenSAML core code doesn't
    know about or have special handling to deal with the specifics or
    peculiarities of any particular DOM impl.  We use the standard DOM
    API, period.  So this is an "environmental" problem.  I'm not
    familiar with Wildfly or  SAAJ, so I can't give you specific
    suggestions unfortunately.  <br class="">
    <br class="">
    <blockquote cite="mid:11F3D334-D82D-42CF-A2CF-2740F57EF9DE@mascanc.net" type="cite" class="">
      <div class=""><br class="">
      </div>
      <div class="">Setting the system property on the
        DocumentBuilderFactory makes wildfly unhappy
        (ClassNotFoundExceptions). </div>
      <br class="">
    </blockquote>
    <br class="">
    That sounds like a good avenue to pursue.  The CNFE's might be
    solvable with classpath adjusting.  Or, figure out if it's possible
    to have SAAJ use the standard built-in Oracle Java Xerces impl,
    rather than whatever it's currently using.<br class="">
    <br class="">
  </div>

-- <br class="">To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net" class="">dev-unsubscribe@shibboleth.net</a></div></blockquote></div><br class=""><div class="">
--<br class="">Anger is a gift, <a href="http://www.mascanc.net/" class="">http://www.mascanc.net/</a>

</div>
<br class=""></div></body></html>