java-idp-testbed : resources -> config

[Tom Zeller]

>>Next step for the testbed, I think, is that the contents of
>>src/main/resources should be moved to a new directory src/main/config,
>>and all resource paths should be specified as
>>"file://{$idp.home}/conf/" rather than "classpath:conf/", for example,
>>for all files in that directory.
>
> I think there was only one classpath reference left in the testbed files,
> in webflow-config.

Right, and there are a couple of "src/main/resources" paths to load
credentials for the sp, no biggie.

> What's interesting is that in order to get ${idp.home} to be usable via a
> system property, you have to plugin the <context:property-placeholder>
> element even if you don't actually use it to define idp.home. That appears
> to install the property lookup support for the other property sources.

Well, I think each <context:property-placeholder> loads an instance of
the underlying post processor bean, which might make reloads|refreshes
more complex, but after I moved configuration resources out of the
classpath, a ClassNotFoundException was thrown for the bean with name
"${idp.session.StorageService}", which makes me think that a post
processor is not able to replace a bean class declaration. This
distracted me yesterday.

Also, not relevant to resource location though, with debug logging,
the "xsi:schemaLocation classpath:" locations throw exceptions, so I
think those have to be moved back to http: instead of classpath: to be
clean with Spring on load. If we can use JAXP 1.5 to control external
location retrieveal, great, but otherwise that is still my AI to
figure out.