OpenSAML user discussion

[Jonathan Tellier <>]

> I'm fairly certain you can load as many as you need with XML files (how
> does openws do it for all the SOAP bits?), but no, I would say it's
> cleaner to have a separate jar than not, no matter what else is involved.

That's exactly what I'm trying to do: load the PAOS related
ObjectProviders by using XML file, just like it's done for the other
ObjectProviders. Now, maybe I'm missing something, but from what I've
understood, the only way opensaml can be informed about a new config
file is to modify its bootstrapping process. I know that in my
application, I could extend the DefaultBootstrap class to add a
reference to my new file, but I initially thought that it would be
better to modify the original bootstrapping process. However, since
you're suggesting otherwise, I could fall back to extending the
bootstrapping process.

In fact, one of the reasons that led me into branching opensaml is
that I though that if and when you guys would want in incorporate my
changes, it would be easier to just diff my branch with the official
one instead of looking at opensaml related changes included in my SP.
Or maybe I'm just getting used with the git way of doing things in
which branching is quite common.

Anyway, I guess it's not really harder to take the PAOS related code
in my SP and incorporate it in the official code tree...

> Bugs are bugs of course, different story.

You're totally right. I should have opened an issue on Jira from the
beginning. I've done it now.
(https://bugs.internet2.edu/jira/browse/JOST-140)

> I'm just hand waving, I'm only partially familiar with the Java code, but
> you would certainly not have to do this with the C++ version, and it would
> be rather bizarre if the Java was somehow less extensible in that regard.

OK, so since everything I'm trying to do is achievable in my SP, I'll
extend opensaml in it instead of maintaining a separate branch.

Thanks,
Jonathan