NPE while marshalling an object

[Brent Putman]

On 6/18/15 10:28 AM, Stephen.CTR.Chappell at faa.gov wrote:
>
> No, I’m sorry I wasn’t clear, it is a web service, and there is no
> main. I meant that this was the primary implementing class for my web
> service; which isn’t really entirely accurate either, I was working
> two similar issues at once and cited the wrong one. Sorry about that.
>

No problem.  In that case, all I was really getting at was: if you are
putting different sets of jars and/or duplicate jars into different
classloaders in a hierarchical classloader environment, you might run
into problems.  I.e. a servlet container will usually have several;
Tomcat for example as "shared" and "common" ones, in addition to the one
for each webapp. It's even worse in a more complex app server like JBoss
and you're doing full blown EJB stuff (or so I hear). If you put all
your dependencies right in your webapp's WEB-INF/lib, that should avoid
any such problems.



> But it looks like I may have solved this issue (and possibly created
> others, but that is another story) – my project also uses CXF and
> WSS4J, and it looks like the WSS4J initialization code doesn’t
> properly initialize everything in OpenSAML, particularly the parser pools.
>

I was vaguely aware WSS4J was updating to OpenSAML 3.x, but didn't know
they had released yet.



> They’ve put a fix in their bootstrapping code, which for the moment
> I’ve cribbed and stuck in my own code; that’s gotten me past the
> immediate issue.
>
>  
>


I just took a quick glance at WSS4J 2.1.1, and yeah, in their
OpenSAMLBootstrap and OpenSAMLUtil, they are adlib-ing with their
approach and not really following what we document
(InitializationService).  They may have a good reason for that (although
I don't know what that is...), but just be aware that there's other
things besides the ParserPool they also aren't doing.  So depending on
what you do with OpenSAML, other things may not work correctly.

If you want specifics, InitializationService just runs all the impls of
the interface: org.opensaml.core.config.Initializer.  An IDE can show
you all the impls of that interface.

Frankly, if they really *can't* use our InitializationService for some
reason, what they (or you) should really do is just instantiate the
individual Initializers desired and invoke them manually.  That would I
think be preferable to just making something up ad hoc.  That's all the
InitializationService actually does.  If someone from WSS4J is on this
list and that doesn't make sense, let me know and I'll explain in detail.




> I’ll look at adding the –impl dependencies as well; it wasn’t really
> clear how everything was broken up, and what I would really need to
> include. I try to run a bit lean if I can; just sucking in everything
> seemed a bit excessive.
>

You don't necessarily need to add *all* the -impls in OpenSAML.  But the
rule of thumb would be that if you use anything from a particular -api,
you probably are going to need the corresponing -impl.  Definitely so if
what you are using is any -api's XMLObject interfaces - the impls,
builders, marshallers and unmarshallers for those are going to be in the
-impl module.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150618/5d0ee850/attachment-0001.html>