Make all configuration resources abstract ?

[Rod Widdowson]

> I guess my questions are : do we want to make all configuration
> resources abstract ? 

You mean, the examples in the config files we ship do not have the type
decorator?  Then I would say "yes, well, maybe"...  

If we did this, then we and our users can then use ResourceLoaders to do
what is needed to say "I know undecorated is file://" and mostly Spring just
gets it right.  But we still have the capability to override where we want
or need to.

> do deployers really use non-file:// resources ?

As Scott says, yes.  Equally there may be reasons post 4.0 for us to move
things from the file:// back into the war: think 'mandatory defaults'.
Finally, do not forget the ResourceBackedMetadataProvider in all this.

> The notion I had was to replace locations of the form
> "file://${idp.home}/conf/..." with "${idp.confDir}/conf/..." so that
> resources paths would be strings prefixed with file: or classpath: or
> even jar: suitable for property replacement.

I'm not sure what you mean.  I'm quite happy with making things work so that
"${idp.confDir}/conf/..." is understood as "file://${idp.confDir}/conf/...".
I'd be less happy to see any manipulation of the string.  We should be just
passing the string into Spring and telling it to give us a Resource out the
other end.  This also gives us the option to pass in Resources as well as
Strings.

 > A stumbling block was that some elements in our Spring bean definition
> files expect a File to be injected, and I was wondering if it was
> worth the time to abstract File to Resource in general.

I would say that these should be changed while we can and that we need to
seek-and-destroy these.  I'll bet that there is one in the ECMA scripted
attribute and filter.  The good news is that 
filePath="c:\foo\bar\fred" is forward compatible with making filePath into a
Resource with a default loader of FileResourceLoader, with the added benefit
that you can then add other types
 
> I was thinking a deployer might deploy their configuration, managed by
> version control, as a jar to be dropped into a container along with
> the war.

I think that that’s weird, but we certainly shouldn't do anything to stop
people doing that..

> It looks like in V2 we default to file system resources, wondering if
> we should make all resources abstract for 3.0 or later if at all.

Again I'm not really sure what you mean by an abstract resource.  V2 has the
file:// all over the place, thus giving people the option to use other
providers, I don't see why we shouldn't do the work to make it default to
file to allow people to remove the decoration, so long as we don't bar
people from specifying "svn://".  OTOH by forcing people to say file:// you
make it clear that this *is* a resource and hence replaceable by other types
(although it is not without costs for windows admins, but we've dealt with
that before).

Finally, you should be aware V2 also has the 'schema' namespace.  I have not
(yet) found out which subschema is referenced from, but the build broken
when I did precipitously remove it.  If we possibly can we should remove
this - I'll report back when I find out who is using it.

/Rod