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

[Brent Putman]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190808/1bbd542c/attachment.html>