OpenSAML user discussion

[Kenny Pearce <>]

Altering XMLTooling according to the patches I submitted on your bug
report and NOT releasing the DOM causes things to work correctly for me,
at least for now. This does NOT solve the namespace problem. Thanks.

On Wed, 2008-04-30 at 20:23 -0400, Brent Putman wrote:
> 
> Kenny Pearce wrote:
> > 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).
> 
> Yeah.  :-)  Could be that both Sun's and latest Xerces are buggy in 
> different respects and we're each basing our recommendation on the 
> specific problems we've run into.  Not an ideal situation, really...
> 
> 
> >  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.)
> >   
> 
> 
> Ok, that sounds like that would cause it.  I did open a bug JXT-32 to 
> update xmltooling to test for that condition.  It's possible that if the 
> adoptNode fails, we could try an importNode as a fallback, and then only 
> throw an error if both fail.  Don't know if that will work, there might 
> be undesirable side effects, have to think about it..... but since it 
> copies the node, that might avoid the case of differing impls.  In fact, 
> if you *are* building and running xmltooling from source and want to 
> give that a try (it's like 2 lines) and let me know...
> 
> 
> >     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.
> >   
> 
> 
> It may or may not be technically a bug, but if adoptNode fails (and if 
> importNode as a fallback proves not workable), then that's probably the 
> only solution.  Except for the total brute force approach of serializing 
> what you get from the other impl, and then reparse and unmarshall using 
> whatever impl is used for opensaml.  That would solve it almost 
> certainly, albeit very inefficiently.  But I think this sort of 
> converting between different XML implementations is often just a fact of 
> life in the web services world...
> 
> >     This still leaves the namespace bug. 
> 
> Sorry, I haven't had a chance to look at that yet.  Maybe tomorrow.
> 
> > 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?
> >   
> 
> Yeah, I took a quick look, I haven't looked at the new XACML stuff much 
> yet.  These appear to be just simple provider bugs and/or config file 
> bugs.  The DescriptionType doesn't have any impl classes, nor a config 
> file entry, so when it's unmarshalled, it gets created as the default 
> provider (XSAny).  But the parent (PolicyType) doesn't handle XSAny's in 
> its processChildElement and so it gets (silently) ignored.  Same for the 
> SubjectMatchType which is child of SubjectType - it doesn't have a 
> config entry, so becomes an XSAny.  Because you drop the DOM, you lose 
> them completely and so not there when you re-marshall.  You mentioned 
> something also about Rules also in an earlier message,  I didn't look at 
> that, but I'll bet it's a similar bug.
> 
> If you turn on TRACE level logging for package org.opensaml.xml.io, you 
> should see some messages to that effect from AbstractXMLObjectUnmarshaller.
> 
> "No unmarshaller was registered for {}, child of {}. Using default 
> unmarshaller."
> 
> File a java-opensaml2 bug on those, and hopefully Håkon can take a 
> look.    There don't seem to be any unit tests for the XACML stuff either.
> 
> --Brent
> 
> 
>