<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 7/31/14 1:14 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CFFFF194.5360D%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 7/31/14, 12:54 PM, "Tom Zeller" <a class="moz-txt-link-rfc2396E" href="mailto:tzeller@dragonacea.biz"><tzeller@dragonacea.biz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Another guess : maybe in MetadataResolverServiceStrategy, the
RelyingPartyMetadataProvider needs a setId() before being initialized.
71 final RelyingPartyMetadataProvider result = new
RelyingPartyMetadataProvider(chain);
72 result.initialize();
</pre>
</blockquote>
<pre wrap="">
I think it's probably something to fix, but right now that class is
calling setId() in doInitialize.</pre>
</blockquote>
<br>
<br>
Not sure if this has been said or not, but looks to me like the root
cause is that the filesystem metadata provider (wherever/whichever
config it's reading) doesn't have an 'id' attribute defined. Looks
like the AbstractMetadataProviderParser just unconditionally does
this:<br>
<br>
<tt>builder.addPropertyValue("id", element.getAttributeNS(null,
"id"));</tt><tt><br>
</tt><br>
<br>
This is slightly unfortunate, b/c the AbstractMetadataResolver ctor
at least tries to ensure that the instance is going to have
*something* for an id by default (a UUID):<br>
<br>
<tt> public AbstractMetadataResolver() {</tt><tt><br>
</tt><tt> <snip><br>
</tt><tt></tt><tt> setId(UUID.randomUUID().toString());</tt><tt><br>
</tt><tt> }</tt><br>
<br>
<br>
I don't know if it should be doing that or not based on what we
decided about id attributes, etc; I think Chad added a lot of UUID
default ids in ctors like that way back. Or maybe I did this one
based on his existing model.<br>
<br>
Looks like the parser is also setting this to lazy init, so that
(maybe?...) probably explains why it's also failing later on a
refresh - which makes the sequence confusing. <br>
<br>
But I think that actual fix is to just figure out what config is
actually loading here and check that the filesystem provider has an
id attribute. If it does have one, then there must be something
else fishy going on somewhere with the parsers or something... <br>
</body>
</html>