OpenSAML user discussion

[Kenny Pearce <>]

Brent,
        Thanks for getting back to me. I've just realized (after reading your
email and considering the points you raise) what the problem must be,
but I'm not sure how to fix it. I am doing my XACML processing using the
enterprise-java-xacml engine
(http://code.google.com/p/enterprise-java-xacml/). The author of that
project claims that the latest version Xerces is seriously buggy and the
version included with recent versions of the Sun JVM works properly
(this, I realize, is exactly the opposite of what the OpenSAML team has
told me). So he is forcing the use of the Sun version when I load in the
policies. Then I am grabbing the policies from the PDP to send them back
to the client in an XACMLPolicyStatementType. So that would be why
adoptNode fails. (I have, however, seen it fail in other circumstances,
so perhaps you should be checking for that condition anyway.)
        At any rate, I wouldn't call it an OpenSAML bug if this weird 
situation
required me to release the DOM before proceeding. That's a fairly
reasonable requirement.

        This still leaves the namespace bug. Plus, the latest thing is that
some of my elements are disappearing. This includes all Description
elements and all the contents of my Subject element, at least. I've only
tried with two policies, so I haven't been able to figure out exactly
what the disappearing elements have in common, other than that there are
several Description elements and all of them disappear. Do you have any
idea what the cause of this might be?

        Thanks,

On Wed, 2008-04-30 at 16:57 -0400, Brent Putman wrote:
> Hi Kenny,
> 
> It's clear to me what's happening here, but it's not clear why (the
> original problem, not the workaround you tried that resulted in the
> namespace issue).  The original DOM exception that you were seeing
> with WRONG_DOCUMENT_ERR is being caused because: at the time the
> elements that were parsed or obtained separately are being appended to
> the new parent DOM element, they are not owned by the same DOM
> Document.
> 
> However, the thing is: our AbstractXMLObjectMarshaller code is
> supposed to handle this case automatically by adopting the child
> Element into the parent's DOM Document before appending.  The relevant
> XMLHelper code is below.  Based on the stack trace, what seems to be
> happening is that 1) XMLHelper#appendChildElement is called by the
> marshaller 2) XMLHelper#adoptElement is called and is purportedly
> succeeding (doesn't throw an error), but doesn't really wind up with
> the child being adopted into the parent's Document 3) the parent
> Node#appendChild is then called, resulting in the error.
> 
> 
>     /**
>      * Appends the child Element to the parent Element, adopting the
> child Element into the parent's Document if needed.
>      * 
>      * @param parentElement the parent Element
>      * @param childElement the child Element
>      */
>     public static void appendChildElement(Element parentElement,
> Element childElement) {
>         Document parentDocument = parentElement.getOwnerDocument();
>         adoptElement(childElement, parentDocument);
> 
>         parentElement.appendChild(childElement);
>     }
> 
>     /**
>      * Adopts an element into a document if the child is not already
> in the document.
>      * 
>      * @param adoptee the element to be adopted
>      * @param adopter the document into which the element is adopted
>      */
>     public static void adoptElement(Element adoptee, Document adopter)
> {
>         if (!(adoptee.getOwnerDocument().equals(adopter))) {
>             adopter.adoptNode(adoptee);
>         }
>     }
> 
> 
> 
> So it would appear that the Document#adoptNode(Node) call in
> adoptElement is failing.  The docs for that method say:
> 
> Returns:
>     The adopted node, or null if this operation fails, such as when
> the source node comes from a different implementation. 
> Throws:
>     DOMException - NOT_SUPPORTED_ERR: Raised if the source node is of
> type DOCUMENT, DOCUMENT_TYPE.
>     NO_MODIFICATION_ALLOWED_ERR: Raised when the source node is
> readonly.
> 
> 
> 
> We aren't checking for a null return value there, so I'm guessing
> that's where it's failing.  Are you using a different XML parsing
> approach or implementation for reading in and parsing your policy
> documents than you use with opensaml itself?  It's either that, or
> else the node adoption is failing for some other reason.  Maybe you
> can supply more info about exactly what you're doing, your
> environment, etc.
> 
> I did test this case with some simple sample code that parsed and
> unmarshalled something from a file and added as a child of a built
> XMLObject and then marshalled the latter.  It worked ok.  So I'm
> guessing you're doing something slightly different.
> 
> If you're building and using xmltooling from source, you might try
> checking for a null return on the adopter.adoptNode(adoptee) call
> above and throwing a runtime exception, just to confirm that that's
> what is really going on.  You might also peek at what are the actual
> implementation classes of the documents/elements of your policy
> documents, versus the ones for the opensaml XMLObject providers after
> they are marshalled.
> 
> --Brent
> 
> 
> 
> Kenny Pearce wrote: 
> > Update on this error: it is caused by the fact that I have my policies
> > in XML, and I unmarshall them and then try to add them. If I release the
> > DOM for the policy and it's children, I don't get this error, but I get
> > a different error. I marshall the whole response to DOM and I can print
> > it out and it looks fine. I then return a DOMSource object (I'm using
> > the JAX-WS Provider interface to implement my IdP). When JAX-WS tries to
> > write this to the stream it gives this error:
> > "javax.xml.stream.XMLStreamException: xmlns has been already bound to
> > urn:oasis:names:tc:xacml:2.0:policy:schema:os. Rebinding it to  is an
> > error". So it appears that an xmlns="" is being added.
> > 
> > Should I have to release the DOM manually? Is there a good way to deal
> > with the namespace issue?
> > 
> > Thanks.
> > 
> > On Wed, 2008-04-30 at 09:42 -0400, Kenny Pearce wrote:
> >   
> > > So, I got the previous problem fixed, but now marshalling is failing
> > > with:
> > > 
> > > org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a
> > > different document than the one that created it.
> > >         at org.apache.xerces.dom.ParentNode.internalInsertBefore(Unknown
> > > Source)
> > >         at org.apache.xerces.dom.ParentNode.insertBefore(Unknown Source)
> > >         at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source)
> > >         at
> > > org.opensaml.xml.util.XMLHelper.appendChildElement(XMLHelper.java:468)
> > >         at
> > > org.opensaml.xml.io.AbstractXMLObjectMarshaller.marshall(AbstractXMLObjectMarshaller.java:162)
> > >         at
> > > org.opensaml.xml.io.AbstractXMLObjectMarshaller.marshallChildElements(AbstractXMLObjectMarshaller.java:317)
> > > etc.
> > > 
> > > I only have this problem when XACML elements are used. Any ideas?
> > > 
> > > On Tue, 2008-04-29 at 17:30 -0400, Brent Putman wrote:
> > >     
-- 
Kenny Pearce 
<>
Hx Technologies