fixing the crypto factory beans

[Cantor, Scott]

On 5/30/14, 11:44 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>I'm not sure what the trade off would be for that, or why we're using
>Generic now, apart from that we did it that way in V2.

I believe we're using Generic instead of the Xml contexts because the
latter don't allow us to load beans into the context alongside other
resources and control when refresh() gets called.

To avoid disrupting anything sensitive, the easy fix, which I applied, is
to derive our own GenericApplicationContext subclass that overrides the
method that handles path-only resources, which is conveniently available.
I just made it return a FileSystemResource and we're done.

As an aside, why is all the custom Spring helper code in idp-core instead
of spring-extensions? I would think we'd want to move it there, it doesn't
depend on any IdP code. I figure anything that doesn't important anything
else from net.shibboleth.idp.* but its own package clases shouldn't be in
the IdP.

Any objections if I move them? It's a large refactor because a lot of the
custom parsers use SpringSupport, but it's not a hard refactor.

-- Scott