Stable schema locations

[Cantor, Scott]

On 2/4/14, 4:28 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>- Might it be possible (for the sake of documentation) to add rewrites to
>tagged versions for each release.  So for instance:
>
>http://shibboleth.net/schema/idp/resolver/V3.0.1/shibboleth-2.0-attribute-
>re
>solver.xsd
>
>Could point to whatever was tagged for that release.  That helps in the
>(rarely, if ever occurring) case where people are trying to use new stuff
>which we introduce with a down level release. And cannot work out why it
>has
>failed.  Of course the odds of use revising the schema again have to be
>disappearingly small, but you never know.

The problem is that won't work as intended unless you change the
spring.schemas files. It will use the remote schemas at runtime when you
start the IdP, and that's not what we want. You can't have the
spring.schemas file out of sync with the schemaLocation header.

I agree that it's a problem, but I don't know what to do about it. The
only options to prevent this are the two I noted. Override Spring
entirely, or maintain spring.schemas per-release.

>- That we make a mental note to ensure that our legacy classpath: urls
>continue to work - for backwards compatibility with the installed base.
>Right now they will, but if we take it into our heads to move the schema
>location in the jar badness will occur - but only for legacy installs.

I don't believe that's a problem based on what I've looked at (but moving
the schemas or renaming them would break it, yes).

-- Scott