<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 3/13/15 6:31 PM, John Landers wrote:<br>
    </div>
    <blockquote
cite="mid:CAEjrYg_VSAu-LTTdKLtxM4mNv3VdVy9FwfK64E2gh5fHMZYbBQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">We ran into an issue that the first call to
        BasicParserPool.parse fails but the second call with the same
        xml doesn't fail.
        <div><br>
        </div>
        <div>I looked through the code and method on BasicParserPool: <span
            class="" style="white-space:pre"> </span>public void
          returnBuilder(DocumentBuilder builder)</div>
        <div>calls </div>
        <div>
          <div><span class="" style="white-space:pre"> </span>unwrappedBuilder.reset();</div>
        </div>
        <div><br>
        </div>
        <div>which resets the entityResolver and errorHandler back to
          the default constructor versions.</div>
        <div>So next time when using a parser from the pool it isn't
          using the BasicParserPool errorHandler </div>
        <div>LoggingErrorHandler so parsing doesn't fail.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    Yes, this is a bug.  I opened issues for both v2 [1] and v3 [2].<br>
    <br>
    For v2 (which it appears you might be using given you had a
    Configuration reference in there) this will be fixed on the main
    code line (branches/REL_2), but I don't think we can guarantee when
    or even if we'll see another v2 release.  You should strongly
    consider moving to v3 sometime in the near future.<br>
    <br>
    As a workaround for v2, I guess you can cast to
    DocumentBuilderProxy, get the proxied DocumentBuilder and set the
    ErrorHandler yourself on every call, or perhaps abstract via a
    subclass that overrides getBuilder().<br>
    <br>
    Also: The BasicParserPool has some inefficiencies because it tries
    to manage mutating properties of the pool over time, and versioning
    the pool and its builders.  We don't actually use it any more in
    Shibboleth.  Instead we use the StaticBasicParserPool, which you
    init once and can't change, so it avoids all the versioning and
    dirty pool config overhead.  (In v3/java-support, we only have the
    static one, confusingly called BasicParserPool.)<br>
    <br>
    Also, related:  In both looks like we don't even offer a way to set
    the EntityResolver.  We have the (private) field there, but there is
    no setter.  Also, the ErrorHandler is internally defaulted; we may
    want to offer a public setter for these as well. [3]<br>
    <br>
    <br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/JOST-241">https://issues.shibboleth.net/jira/browse/JOST-241</a><br>
    <br>
    [2] <a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/JSPT-54">https://issues.shibboleth.net/jira/browse/JSPT-54</a><br>
    <br>
    [3] <a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/JSPT-55">https://issues.shibboleth.net/jira/browse/JSPT-55</a><br>
  </body>
</html>