OpenSAML user discussion

["Cantor, Scott E." <>]

>Well, here are my major reasons.
>
>- To configure ObjectProviders. This can be achieved programatically,
>but isn't cleaner to have them configured in XML files alongside the
>other ObjectProviders?

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.

I'm not saying the PAOS bits shouldn't be in the code we distribute, but
if there's some resistance to that for some reason, you would want to, for
now, have a separate jar, not a hacked opensaml jar.

>- To define XML schemes.

I don't follow. Schemas should be pluggable, I can't think how they
wouldn't be. It's just up to an entity resolver in the parser to find them.

>- There's also this small thing that I corrected in this commit
>regarding the HTTPSOAP11Decoder:
>http://gitorious.org/java-opensaml-paos/java-opensaml-paos/commit/179353c6
>788e58eb3f5b696119e5c1df03cab46b.

Bugs are bugs of course, different story.

>However, if those reasons are not valid, I'd be happy to be explained
>why. That would relieve me of having to maintain a separate opensaml
>branch.

Apart from bug fixes, I don't think they're valid. And bug-wise, I think
you can just create your own version of the decoder for now, and
Spring-inject it anyplace you need the fixed version until the official
one is fixed. At least I assume so.

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.

-- Scott