Alpha2 Metadata Error on Start

[Brent Putman]

On 7/31/14 1:14 PM, Cantor, Scott wrote:
> On 7/31/14, 12:54 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>> Another guess : maybe in MetadataResolverServiceStrategy, the
>> RelyingPartyMetadataProvider needs a setId() before being initialized.
>>
>> 71 final RelyingPartyMetadataProvider result = new
>> RelyingPartyMetadataProvider(chain);
>> 72 result.initialize();
> I think it's probably something to fix, but right now that class is
> calling setId() in doInitialize.


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:

builder.addPropertyValue("id", element.getAttributeNS(null, "id"));


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):

    public AbstractMetadataResolver() {
           <snip>
        setId(UUID.randomUUID().toString());
    }


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.

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. 

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140731/5c65cc3e/attachment-0001.html