java-idp-testbed : resources -> config

[Tom Zeller]

>>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.
>
> Hmm, ok.

Here is the debug log :

DEBUG o.s.b.f.s.DefaultListableBeanFactory - Ignoring bean class
loading failure for bean 'shibboleth.StorageService'

Caused by: java.lang.ClassNotFoundException: ${idp.storage.ClientStorageService}
 at java.net.URLClassLoader$1.run(URLClassLoader.java:366) ~[na:1.7.0_45]

the property is not replaced upon bean instantiation, it appears. The
workaround is easy, just don't use a property for the class attribute
in a <bean> definition.

>>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.
>
> May just be an error in a particular location, I had debugged those
> earlier.

The classpath schemaLocation is only supported by Spring, so it catches

DEBUG o.s.b.f.xml.ResourceEntityResolver - Could not resolve XML
entity [classpath:/org/springframework/beans/factory/xml/spring-beans-3.2.xsd]
against system root URL

java.net.MalformedURLException: unknown protocol: classpath
 at java.net.URL.<init>(URL.java:592) ~[na:1.7.0_45]

and does the "right thing".

Just not sure if schemaLocations will ever be read outside of Spring.





>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net