NPE while marshalling an object

Thu Jun 18 15:25:52 EDT 2015

Thanx for the detailed response, Brent! For the current project, initializing the parser pools was all I needed to move on to the next set of issues, so I think I am ok for now. The next bit of code to be migrated is much larger though, and so might need some additional capabilities; this'll help me build a custom bootstrap when I get there.

Thanx again,

Stephen W. Chappell

From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Brent Putman
Sent: Thursday, June 18, 2015 3:19 PM
To: dev at shibboleth.net
Subject: Re: NPE while marshalling an object

On 6/18/15 10:28 AM, Stephen.CTR.Chappell at faa.gov<mailto: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/120488ce/attachment.html>