XML Implementation issues

[Massimiliano Masi]

Hi, 

FYI, I solved it. 

The idea is the following. Setting is wildfly 9, opensaml, 2.6, 3.x, java8. 

In wildfly it is not so easy to predict which DocumentBuilderFactory is used, given the “redirect” mechanism. In fact, in https://github.com/jboss-modules/jboss-modules/blob/master/src/main/java/__redirected/__DocumentBuilderFactory.java <https://github.com/jboss-modules/jboss-modules/blob/master/src/main/java/__redirected/__DocumentBuilderFactory.java>, it is stated a JAXP bug in the FactoryFinder, 
which is exactly what I was facing. 

On the other hand, when an Element is unmarshalled by xmltooling in the context above, it gets its DOM associated using the SAAJ. 
Here, there is a funny thing: they overcome for whatever reason the FactoryFinder and they always instantiate the com.sun.org <http://com.sun.org/>.apache.xerces, 
using a plain new(). 

Results: when marshalling, the opensaml’s ParserPool gets the implementation from wildfly (the BasicParserPool uses the FactoryFinder)
but then, in the XMLHelper, in the adoptNode, the underlying implementation (which is xerces in wildfly, see here: https://developer.jboss.org/thread/272018 <https://developer.jboss.org/thread/272018>) returns null, and thus XMLHelper throws the “DOM Element Node Adoption Failed”. 

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, 
as per the TCCL as above. 

The workaround that I found is the following. The the Configuration.getParserPool().getBuilder().getDOMImplementation(), then get the DOM 
implementation from the xmlObject.getDOM(), and check if they are the same. If not, take the DOM from the XML Object, create a new
DocumentBuilder out of the Configuration.getParserPool().getBuilder(), dump the xmlObject’s DOM to a byte array, parse it, and call the 
xmlObject.setDOM(newDOM). Then marshall it. 

HTH, 

	Massi



> Il giorno 10 ago 2016, alle ore 18:02, Brent Putman <putmanb at georgetown.edu> ha scritto:
> 
> 
> 
> On 8/9/16 11:51 AM, Massimiliano Masi wrote:
>> Hi All, 
>> 
>> I am running java 1.8 and wildfly 9. I have some issues with the DOM implementation, opensaml 2.6.1. 
>> 
> 
> 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 ...
> 
> 
>> My soap message is handled by saaj. When I get the SOAP header, and I unmarshall it, the DOM is 
>> 
>> com.sun.xml.messaging.saaj.soap.impl.ElementImpl 
>> 
> 
> 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).
> 
> 
>> 
>> 
>> 
>> 2016-08-09 17:46:38,515 INFO  [stdout] I got an exception. My implementation is: class org.apache.xerces.dom.NodeImplfrom: 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!/>
>> 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
>> 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
>> 2016-08-09 17:46:38,515 ERROR [stderr] 	at org.apache.xerces.dom.CoreDocumentImpl.adoptNode(CoreDocumentImpl.java:1760)
>> 2016-08-09 17:46:38,515 ERROR [stderr] 	at org.opensaml.xml.util.XMLHelper.adoptElement(XMLHelper.java:545)
>> 
> 
> 
> 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.
> 
>> (
>> 
>> Now, I really don’t know how to proceed. Any hints on aligning the DOM implementations? Before, with java6 and 
>> jboss4, I was used to the endorsing mechanism, but in java8 + wildfly9 it does not seem to have any effect.
> 
> 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.  
> 
>> 
>> Setting the system property on the DocumentBuilderFactory makes wildfly unhappy (ClassNotFoundExceptions). 
>> 
> 
> 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.
> 
> -- 
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

--
Anger is a gift, http://www.mascanc.net/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160825/1f294d75/attachment-0001.html>