Resources.

[Rod Widdowson]

I’ve been looking at code and talking to a few people about resources.  As I
understand it, the problem statement is:

- We do not want to tie OpenSAML (or java-support) to Spring.
- But OpenSAML at least does have a (limited) need for Resource type object.
- However we see no reason to have classes which duplicate Spring function.

It turns out that OpenSAML’ s use of resources is very limited – outside
testing only the ResourceBackedMetadataResolver provider uses them and its
use is an exact subset of the Spring Resource interface.

So, to use Brent’s words, the proposal is 

“[To] standardize on the Spring Resource API everywhere except OpenSAML (and
maybe java-support) where, to avoid a Spring dependency, we'll have a simple
clone of the Resource interface (with no impls) and then a Spring
Resource-wrapping impl in the IdP.  Assume all actual impls at runtime will
actually be Spring ones (or wrap a Spring one).”

I should also amend that to say that we _are_ at liberty to replace the
Spring implementations (for instance the HTTP resolver might require
additional parameterization) and to add our own resources (notably we need
want to add support for “svn:”).  More knowledgeable people than I can
comment, but it seems that this can be done by just extending the
appropriate (Spring) context to add in the correct ResourceLoader.

It is not clear to me whether we need to duplicate the filtering subsystem
(see the bottom of
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfigResource) just
to be able to do replacement into those resource streams we parse ourselves,
or whether we can use the Spring's property placeholder. It seems that to do
that we would need to revert to using factory beans again -
http://stackoverflow.com/questions/12936080/using-a-properties-file-with-a-c
ustom-bean-parser. But do we feel the need for this?  Can we not just state
that if we want to drive configuration from a properties file we just write
the native spring XML to do it?

Precisely how we achieve this move to Spring Resources is open to
discussion.  My suggestion would be to use eclipse’s refactoring capability
to rename the existing Resource interface and then deprecating it (and it’s
implementations).  Then we can introduce a new Resource interface (which is
method for method identical with the Spring one).  Finally we go through the
code replacing the deprecated  interface + implementations with the new
interface and spring implementations.

Finally, I’ll mention reload, because we all agree that resources are the
easy thing, and the hard thing is reload and bean lifecycle (and in
particular correctly timed destruction).  However to keep this mail thread
focussed.  I’ll start a new thread for that.  I am pretty close to be able
to do so, but I’d like to do a little bit more nature study first.

Rod