Are we actually using the spring.schemas files?

[Cantor, Scott]

On 2/2/14, 7:06 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>So, I made the change to the 'spring.schemas' file that Scott suggested:
>
>urn\:mace\:shibboleth\:2.0\:resolver\:ad=schema/shibboleth-2.0-attribute-r
>es
>olver-adXXXXXXX.xsd
>
>And nothing broke.

Same for me. This "fits", because the V3 code isn't overriding the
DocumentLoader, which means Spring is operating on the schemaLocation
value now, not the namespace like it was in V2.

>However when I changed a test file to
>
>    xsi:schemaLocation="
>
>		[SNIP]
>		urn:mace:shibboleth:2.0:resolver:ad
>random:schema/shibboleth-2.0-attribute-resolver-ad.xsd
>                	[SNIP]"
>
>Things broke, but when I added
>
>random\:schema/shibboleth-2.0-attribute-resolver-ad.xsd=schema/shibboleth-
>2.
>0-attribute-resolver-ad.xsd
>
>to 'spring.schemas' things started working again.

That's what I couldn't get to work. Did you do this in the unit tests, or
in the actual testbed?

>So the answer is not that we are not loading the files, it is just that
>they
>are full of junk.

Yes, to be clear I wasn't suggesting we had the right content in them,
just that I could get them to work the way I thought they should be.

>It seems like the issue now is that we have a lot of legacy files which
>are
>also valid classpath-uri locations (for instance  classpath:schema/
>shibboleth-2.0-attribute-resolver-ad.xsd)

Yes, basically we have all the instances now mostly pointing directly to
classpath locations. So that works, because the default EntityResolver
Spring uses will fall back to trying a ResourceLoader against a classpath
URI if you give it one. That's why the currently broken content of
spring.schemas isn't breaking anything.

>I did about 5 minutes experimentation and it turns out that if you put
>this
>classpath-uri (suitably escaped) on the LHS of the 'spring.schemas' file,
>the right thing almost happens, in that if the schema is found at the
>pointed-to location it is loaded in preference to the one pointed to by
>the
>classpath-uri.  If however there is nothing at the pointed-to location
>then
>the classpath-uri is looked at.  I think, YMMV &c.

Hmm, that makes me wonder if the problem was what I was putting into the
RHS of the mappings. If it's falling back to the LHS, that would explain
what I saw. What did you actually use on the RHS in your testing? I was
just following the Spring docs and using what we had in the files already,
paths like "schema/foo.xsd".

-- Scott