<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 1/31/14 3:34 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF11730B.48AE3%25cantor.2@osu.edu" type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
That's troubling/surprising. <br>
<br>
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.<br>
<br>
This is btw using a context instantiated in the simple manner via:
new ClassPathXmlApplicationContext("customContext1.xml").<br>
<br>
So I'd conclude basically that whatever we're doing as far as Spring
context parsing/loading/init is just horked. <br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:CF11730B.48AE3%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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).<br>
<br>
<br>
<br>
<blockquote cite="mid:CF11730B.48AE3%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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 <a class="moz-txt-link-freetext" href="http://">http://</a> 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.
</pre>
</blockquote>
<br>
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 ).<br>
<br>
And of course if you can overcome your pathological aversion to
schemaLocation. ;-) <br>
<br>
<br>
</body>
</html>