using Velocity to externalize configuration properties ?

[Cantor, Scott]

On 8/5/13 10:07 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 8/5/13 8:58 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>>I just happened upon XMLBeanDefinitionReader#setDocumentLoader()
>>
>>Which takes one parameter of type
>>org.springframework.beans.factory.xml.DocumentLoader.  This is an
>>interface
>>with but one method which effectively takes an org.xml.sax.InputSource, a
>>org.xml.sax.EntityResolver and a few other things and produces a
>>org.w3c.dom.Document from them.
>
>There's also the EntityResolver itself, which is the code that's actually
>doing what I want to change. The code Chad wrote that manually creates a
>GenericApplicationContext could be modified to install a loader or entity
>resolver of choice on the XmlBeanDefinitionReader it's creating.

Specifically, the code that's allowing remote schema access is
org.springframework.beans.factory.xml.ResourceEntityResolver. It delegates
to the classpath-based lookups that use those spring.schemas files and
then runs if that doesn't work.

It just resolves anything it gets into a Spring Resource. Blacklisting
http and https URLs there is likely sufficient to prevent remote lookup.

It really depends what we want to do about the classpath: syntax, if
anything. That will continue to break editors, and I think one approach is
to extend it to turn scheme://path/file.xsd URLs into
classpath:/schemas/file.xsd.

Actually getting rid of the dependency on schemaLocation is a farther
step. While I think that would be really nice, it means building a catalog
of our own to map namespaces to resources and of course maintaining it to
include all the Spring schemas that might be needed.

I don't know if they all follow this convention, but the main ones appear
to be http://www.springframework.org/schema/foo mapping to
foo/spring-foo.xsd

-- Scott