Resources.

[Tom Zeller]

> 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).”

Sounds good to me.

Rod, a wiki page describing the changes to Resources in v3 might be
nice someday.

> ... duplicate the filtering subsystem ...
> 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?

I would feel comfortable making the decision to wire back in the
factory beans in v3 to support post-processing, especially as we are
(a) avoiding new extensible XML authoring and we are (b) using Spring
more, meaning Web Flow, Resources, native XML config for the
LDAPDataConnector, etc.

If we so choose, the work should be straightforward, like house painting.

Open to discussion ...

> 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.

I would probably start by deprecating Resource, and then create a
SpringResource. I guess I find renaming-then-deprecating potentially
more confusing to follow.