Null Pointer Exception from UnmarshallerFactory while migrating from OpenSAML2.x to OpenSAML3.x

[DD K]

Hi Brent,

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.

Regards,
Deshan Koswatte

On Fri, Aug 9, 2019 at 3:11 AM Brent Putman <putmanb at georgetown.edu> wrote:

>
> On 8/8/19 11:07 AM, DD K wrote:
>
> Hi All,
>
> 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.
>
> Stack Overflow Resource -
> https://stackoverflow.com/questions/37948303/opensaml3-resource-not-found-default-config-xml-in-osgi-container
>
>
> 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.
>
> 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.
>
> 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).
>
> 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.
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190814/4340c366/attachment.html>