Resources.

[Cantor, Scott]

On 12/16/13, 11:39 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>I have just made the latest series of changes in this stream.  Apart from
>now-deprecated code awaiting being moved, java-support only knows about a
>single Interface (ShibbolethResource) which, as discussed previously, is
>method-for-method compatible with the Spring one.  OpenSAML has been
>modified to consume this and to use (in the tests cases) helper method:

Is that interface temporary? Asking whether I should suggest an alternate
name.

>The SVN will (re)introduce a new dependency on SVNKIT.  This has a license
>which I'd like someone to eyeball at http://svnkit.com/license.html.  It
>looks OK, but I am no expert.

I think it's got a red flag in it, the source code distribution
requirement. That would essentially preclude people using our code as
intended by the Apache license.

I'm guessing we're already vulnerable on this, we probably use svnkit now,
right?

This sounds like something that could be marked as "optional" at least in
V2, but I think I'd be against using it in V3.

>However a next step might be a desire to summon up resources via the
>ResourceLoader interface (hence a configuration file might say
>"svn+ssh://shibboleth.net/mumble").  Although the ResourceLoader but is
>probably not difficult, it is not immediately obvious to me how to pass in
>all the extra parameterization that these specialist resources require.

If I understand the issue, I think there are probably two ways of doing
this, one limited to only certain use cases. If a bean could be created
that acts to load additional resources, then I think you could create
fully-configured Resource beans and inject them into the loader bean and
have it load the resource into the parent context. But that only works for
some scenarios, anything built-in that only took a URI probably couldn't
be used.

The really ugly way is to bury the configuration into part of the custom
URL syntax.

-- Scott