Make all configuration resources abstract ?

[Rod Widdowson]

> There may be cases where it also just makes sense to change the delivered
> bean file to turn the whole Resource URI into a property and not include
> idp.home in the expression.

I agree.  

As a question, does property replacement "do the right thing" iteratively?
So does:

idp.confDir=\opt\whereever
idp.attribute.resolver.file=${idp.confDir}\conf\attribute-resolver.xml

Do what you'd expect?

However, and this is slight related, we need to be slightly careful here.  I
believe that we are going to have to move some beans from system/conf/system
to conf/user, so as to allow our advanced users access to them.

Specifically I see us moving lines like this:

<property>
  <list>
    <value>${idp.home}/conf/attribute-resolver.xml</value>  <!-- or possibly
${idp.attribute.resolver.file} -->
  </list>
</property>

to global-user. This allows the more advanced user to conjure up Resources
of their own making.  For they might want to use a HttpClientResource with
non obvious setting of the HttpClient, or to inject the property replacement
code.  At the same time the default works from idp-properties.

As I noted in the earlier mail, the trick is that spring knows how to turn a
String into a Resource, however that does not preclude people from directly
injecting resources.