Alpha2 Metadata Error on Start

[Rod Widdowson]

After some revision and a fair bit of research I have found the issue.

We are in the middle of initializing the MetadataResolverService and this
has indirectly caused the initialize of the FilesystemMetadataResource.  The
initialize has provoked a initMetadataResolver() (in
AbstractMetadataResolver) which has provoked a refresh() (in
AbstractReloadableMetadataResolver()).  At this stage we know that the
FilesystemMetadataResource has initialized correctly (and that is what was
confusing us all).

The metadata is loaded and then the (XMLObject) filters are run.  One of the
filters is the one which does the conversion from SAML attributes to
IdPAttributes (as Tom deduced).  

The way that this works is that the filter takes an AttributeResolverService
which is "mined" to create the mappers.  This is mining is done (by the
filter) on first use and whenever it notices that the Service has been
reloaded.  Note that the AttributeResolverService does *not* perform the
mapping, it just serves as the source of the information which allows us to
build the mapping (this is mostly for historic reasons, but it also seems to
makes sense to not overload the service which is really about attribute
resolution only (the encoding happens as a side-effect - the encoder is
added at resolution time).

Anyway in this case this is first used and so the filter tries to create the
mapper from the AttributeResolverService and then initialize it.  It is
during the mapper's creation (not, in fact, initialization) that the setId
fails and it appears from one of the traces that this is the failing line:

        mapper.setId(getFriendlyName());

So in the immediate there is one workaround and (at least) two bugs:

Workaround:  Marvin - can you check that all your
SAML2ScopedAttributeMappers define a friendlyName.  This should make the
problem go away (or be replaced by another)

Bug#1:  The mapper creation code has an assumption that getFriendlyName()
returns non-null.  This needs to be fixed .  I have entered case IDP-458 for
that case.

Bug#2: As per IDP-456 we were logging the exceptions incorrectly.  This made
this problem needlessly hard to diagnose.

In the longer term there is a question of whether we should promote
attribute mapping up to being a service offered by the attribute resolver.
This would at mean that attribute mapper configuration errors would happen
as a result of initialization of the attribute mapper.  Alternatively we
could do is create the mapper when the encoder is initialized which would
have much the same effect.   I'm not convinced - if the logging had been
correct this would have been an easier problem to diagnose.

/R