Are we actually using the spring.schemas files?

[Brent Putman]

On 1/31/14 3:34 PM, Cantor, Scott wrote:
> I've been investigating the situation with Spring schema lookup using the
> attribute resolver unit tests, and I've concluded that at least in the
> unit testing case with Eclipse or Maven, the spring.schemas file in the
> idp-attribute-resolver-spring module is never used.

That's troubling/surprising. 

Since our v2 Spring custom schema stuff has been broken from day 1, I
realized have never actually personally seen or implemented a working
custom schema and Spring namespace handler, as it is meant to be.  So, I
just spent a few minutes (literally like 10 minutes) coding up the most
simple hello world type of custom schema and handler example for a
custom bean.  I can confirm that at least in a plain Jane Spring
environment, the schema stuff does indeed work as advertised.  My
schemaLocation is pointing to a bogus brentputman.org URL location for
the XSD, but the schema correctly gets loaded from the classpath via the
spring.schemas data.  If I remove the spring.schemas file, or comment
out its contents, then the context init fails with a schema lookup error
as expected.

This is btw using a context instantiated in the simple manner via: new
ClassPathXmlApplicationContext("customContext1.xml").

So I'd conclude basically that whatever we're doing as far as Spring
context parsing/loading/init is just horked. 

Can you point me at exactly what you're testing?  I don't actually see
any tests with Spring config files, etc in for example
idp-attribute-resolver-*, so I'm probably looking in the wrong place.  I
was just wondering exactly what we're doing now in v3 as far as all the
Spring custom parsing stuff.




> I recall that we used to be manipulating the Spring loader such that we
> were mis-using the schema mappings file but it didn't matter, but I don't
> think we're using a custom DocumentLoader in V3. So I'm a little confused,
> something isn't working as it's meant to.

I haven't been tracking this stuff in v3. Are we still using some of
Chad's Spring helper code from v2?  If so, perhaps the problem lies
therein, in that it is somewhere inconsistent with how one is supposed
to do things (as opposed to how v2 did it).



> My sense was that rather than try and torture Spring into doing the right
> thing, we should just use schemaLocation in the config files to point to
> actual http:// locations for editing purposes, and then use spring.schemas
> to fix the loading at runtime to be local. But that doesn't seem to work.
>

That sounds fine to me also. Preserving schema-driven editing support
would be nice, at least, as long as we're confident that the IdP schema
resolution at runtime is in reality happening locally (which it seems to
be capable of doing ).

And of course if you can overcome your pathological aversion to
schemaLocation. ;-)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140131/c68777b8/attachment.html