Creating an XMLObject

[Camel Guy]

Hello,

Thank you for your help and your patience.

I'm using idP v3.1.1

I'm building the XML with Groovy's XMLMarkup because I am not a masochist
(or so I thought).

My document looks like:

<n:attributes xmlns:n='foo'>
  <n:attribute n:name='AcctId' n:value='000004D' />
</n:attributes>

This is just a sample document. I put everything in a namespace to try to
work around the error I've run into (read on..).

The code is as follows. Thank goodness for Moore's law.

Document doc = DocumentBuilderFactory.*newInstance*()
 .newDocumentBuilder().parse( *new* InputSource( *new* StringReader(
xmlString ) ) );
Element elem = doc.documentElement;
XMLObject xml = XMLObjectProviderRegistrySupport.*getUnmarshallerFactory*().
 getUnmarshaller(elem).unmarshall(elem);
I'm getting the same error as described in
http://shibboleth.net/pipermail/users/2015-July/022646.html

A bit of the stack trace:

net.shibboleth.utilities.java.support.logic.ConstraintViolationException:
Local name cannot be null or empty
at
net.shibboleth.utilities.java.support.logic.Constraint.isNotNull(Constraint.java:227)
~[java-support-7.1.1.jar:na]
at
net.shibboleth.utilities.java.support.xml.QNameSupport.constructQName(QNameSupport.java:79)
~[java-support-7.1.1.jar:na]
at
net.shibboleth.utilities.java.support.xml.QNameSupport.getNodeQName(QNameSupport.java:102)
~[java-support-7.1.1.jar:na]
at
org.opensaml.core.xml.io.UnmarshallerFactory.getUnmarshaller(UnmarshallerFactory.java:86)
~[opensaml-core-3.1.1.jar:na]
at
org.opensaml.core.xml.io.UnmarshallerFactory$getUnmarshaller.call(Unknown
Source) ~[na:na]


Thank you,
~cg



On Mon, Oct 5, 2015 at 10:24 AM, Brent Putman <putmanb at georgetown.edu>
wrote:

>
>
> >
>> > static XMLObject
>> unmarshallFromInputStream(net.shibboleth.utilities.java.support.xml.ParserPool,
>> InputStream)
>> >
>> > But I'm not sure whether this is the right method
>>
>
>
> Assuming that's from XMLObjectSupport, either that one or the other one
> that takes a Reader (XMLObjectSupport. unmarshallFromReader( ... )), as you
> already found below, are going to be the simplest way.
>
> Essentially the steps are: 1) parse the input source to a DOM Document 2)
> unmarshall the Document's root element (Document#getDocumentElement()) into
> an XMLObject.
>
> That basic process never really changes.  Those 2 XMLObjectSupport methods
> are just helpful utility methods that hide the details of all that, handle
> error conditions, etc.
>
>
>
> On 10/5/15 12:59 PM, Camel Guy wrote:
>
> XMLObjectSupport. unmarshallFromReader( ... )
>
> Passing a BasicParserPool and a StringReader wrapping a string that
> contains XML, I get:
>
> 2015-10-05 09:50:29,884 - ERROR
> [org.opensaml.core.xml.util.XMLObjectSupport:213] - Unable to unmarshall
> Reader, no unmarshaller registered for element attributes
>
>
> Yeah, I don't know what the error is based on that.  The line number and
> log text there don't match up with the latest trunk.  Exactly what version
> of the IdP are you running here?
>
>
> I need to parse XML, not unmarshal binary goo, so XMLObjectSupport appears
> to be a dead end.
>
>
> It's not, it's exactly what you need.  At least the simplest way.
>
> You need to clarify what your "XML" is.  In general that's not a
> meaningful description.  You probably mean a String serialization of an XML
> structure, and so a Reader or InputStream is exactly what you need there.
> It's not binary goo.  If you were doing this with plain old Java and JAXP,
> you'd still need to parse that "XML" into a DOM Document.  It's no
> different here.
>
> Would also be helpful to know where/how you're getting this XML (reading
> from a file?  building yourself on-the-fly?).  And what it actually looks
> like (the content).  If it's not a type supported by the existing XMLObject
> providers registered in the system for known schemas, then you'll need to
> understand how to work with the structure you get back - probably an XSAny
> instance, which is sort of a generic type able to represent any content
> model.
>
> Re: reading/parsing an some XML serialization:  if you are currently
> building this on the fly, it might be simpler to actually just build the
> XMLObject in your code, as opposed to trying to parse something
> unnecessarily, like building up a String and then parsing it (although the
> latter is perfectly possibly, just inefficient - both performance-wise and
> developer-wise).
>
> --Brent
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151005/95a440ef/attachment-0001.html>