<div dir="ltr"><div>Hello,</div><div><br></div><div>Thank you for your help and your patience.</div><div><br></div><div><div>I'm using idP v3.1.1</div></div><div><br></div><div>I'm building the XML with Groovy's XMLMarkup because I am not a masochist (or so I thought).</div><div><br></div><div><div>My document looks like:</div><div><br></div><div><n:attributes xmlns:n='foo'><br>  <n:attribute n:name='AcctId' n:value='000004D' /><br></n:attributes></div><div><br></div><div>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..).</div></div><div><br></div><div>The code is as follows. Thank goodness for Moore's law.</div><div>







<p class=""><span class="">     </span><span class="">    </span><span class="">    </span><span class="">    </span>Document doc = DocumentBuilderFactory.<i>newInstance</i>()<br> .newDocumentBuilder().parse( <span class=""><b>new</b></span> InputSource( <span class=""><b>new</b></span> StringReader( xmlString ) ) );<br>Element elem = doc.documentElement;<br>XMLObject xml = XMLObjectProviderRegistrySupport.<i>getUnmarshallerFactory</i>().<br> getUnmarshaller(elem).unmarshall(elem);</p></div><div>I'm getting the same error as described in</div><div><a href="http://shibboleth.net/pipermail/users/2015-July/022646.html">http://shibboleth.net/pipermail/users/2015-July/022646.html</a></div><div><br></div><div>A bit of the stack trace:</div><div><div>







<p class="">net.shibboleth.utilities.java.support.logic.ConstraintViolationException: Local name cannot be null or empty<br>at net.shibboleth.utilities.java.support.logic.Constraint.isNotNull(Constraint.java:227) ~[java-support-7.1.1.jar:na]<br>at net.shibboleth.utilities.java.support.xml.QNameSupport.constructQName(QNameSupport.java:79) ~[java-support-7.1.1.jar:na]<br>at net.shibboleth.utilities.java.support.xml.QNameSupport.getNodeQName(QNameSupport.java:102) ~[java-support-7.1.1.jar:na]<br>at org.opensaml.core.xml.io.UnmarshallerFactory.getUnmarshaller(UnmarshallerFactory.java:86) ~[opensaml-core-3.1.1.jar:na]<br>at org.opensaml.core.xml.io.UnmarshallerFactory$getUnmarshaller.call(Unknown Source) ~[na:na]</p>
<p class=""><br></p><p class="">Thank you, <br></p></div><div>~cg</div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 5, 2015 at 10:24 AM, Brent Putman <span dir="ltr"><<a href="mailto:putmanb@georgetown.edu" target="_blank">putmanb@georgetown.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <blockquote type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote"><br>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
              ><br>
              > static XMLObject
              unmarshallFromInputStream(net.shibboleth.utilities.java.support.xml.ParserPool,
              InputStream)<br>
              ><br>
              > But I'm not sure whether this is the right method</span><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br></span>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<span class=""><br>
    <br>
    <br>
    <br>
    <div>On 10/5/15 12:59 PM, Camel Guy wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <p>XMLObjectSupport. unmarshallFromReader( ... )</p>
        <p>Passing a BasicParserPool and a StringReader
          wrapping a string that contains XML, I get:</p>
        <p>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</p>
      </div>
    </blockquote>
    <br></span>
    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?<span class=""><br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <p>I need to parse XML, not unmarshal binary goo, so
          XMLObjectSupport appears to be a dead end.</p>
      </div>
    </blockquote>
    <br></span>
    It's not, it's exactly what you need.  At least the simplest way.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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).<span class="HOEnZb"><font color="#888888"><br>
    <br>
    --Brent<br>
    <br>
    <br>
  </font></span></div>

<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div>