<div dir="ltr"><div><div><div>Hi Brent,<br><br></div>First of all sorry for the late reply. As you've said the way I'm doing is not recommended I had to think a bit on the way to get the initialization process correctly. In the initialization process the file org.opensaml.core.config.Initializer is called to initialize the required, but since I'm getting the dependencies using an orbit seems the file gets overridden and at last the final dependency's initializers would be the only remaining. So to fix this I'm making an orbit for each dependency so that they won't get bundled together which will not override the file, I've currently done it for only one dependency and im planning on doing it to all.<br><br></div>Regards,<br></div>Deshan Koswatte<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 9, 2019 at 3:11 AM Brent Putman <<a href="mailto:putmanb@georgetown.edu">putmanb@georgetown.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="gmail-m_8042889389011648950moz-cite-prefix">On 8/8/19 11:07 AM, DD K wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>
          <div>Hi All,<br>
            <br>
          </div>
          Since I was using OpenSAML3 on a project which is based on
          OSGi seems there was a problem during initialization so what I
          had to do is initialize them myself. Hope this helps someone
          in the future.<br>
          <br>
        </div>
        <div>Stack Overflow Resource - <a href="https://stackoverflow.com/questions/37948303/opensaml3-resource-not-found-default-config-xml-in-osgi-container" target="_blank">https://stackoverflow.com/questions/37948303/opensaml3-resource-not-found-default-config-xml-in-osgi-container</a><br>
        </div>
      </div>
      <br>
    </blockquote>
    <p><br>
    </p>
    <p>If the library init problem is related to use with OSGi, then
      that at least sheds more light on the problem.   It would have
      been nice if the people who discovered this 3+ years ago had
      actually brought this up with us, rather than just cooking up and
      promoting those "solutions" in a StackOverflow thread.  Our team
      doesn't generally use or know much about OSGi, but we would have
      at least researched and determined if there is a supportable
      solution.</p>
    <p>Manually invoking the Initializer impls like that is not
      supported.  With the exception of the ones that are in the
      opensaml-core module, those are all implementation classes, for
      which we provide absolutely no guarantee of stability, such as the
      package/class names, what inits what and provides what, etc.  Your
      calling of those classes could literally break at any time, even
      in a patch release.  The API for calling the Initializers is
      InitializationService, nothing else.</p>
    <p>I don't personally know or use OSGi.  Skimming the SO article, I
      gather that the issue within OSGi is use of the thread context
      classloader failing vis-a-vis where the config resources are
      located in the jars.  The proper solution here would be to figure
      out precisely what assumptions are wrong and address those
      directly.  Perhaps allowing an optional ClassLoader to be passed
      to the InitializationService could be part of that solution (the
      swapping out of the TCCL looks like a decent workaround til then).</p>
    <p>If someone who knows OSGi can provide suggestions and/or a patch,
      we'd consider it.  If it requires API changes however, that would
      be a 4.0 thing, as we currently don't plan on releasing any new
      minor releases of 3.x.<br>
    </p>
  </div>

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