RelyingPartyMetadataProvider logs a null ID

Description

The RelyingPartyMetadataProvider logs a null id.

To reproduce, increase logging to DEBUG in conf/logback.xml :

<logger name="net.shibboleth.ext.spring.service" level="DEBUG"/>

and reload the MetadataResolverService :

bin/reload-service.sh -id shibboleth.MetadataResolverService

The logs will contain a null id :

DEBUG [AbstractServiceableComponent:102] - Component 'null': Component unload called
DEBUG [AbstractServiceableComponent:114] - Component 'null': Closing the appcontext

Commit 4462ff4 adds the IdentifiableBeanProcessor to the MetadataResolverService, but is only on the master branch, not maint-3.3.

The RelyingPartyMetadataProvider needs to implement IdentifiableComponent for the IdentifiableBeanProcessor to take affect.

Environment

None

Activity

Tom Zeller 
November 6, 2017 at 11:51 PM

Looks good.

Scott Cantor 
November 6, 2017 at 9:56 PM

Just checked in a fix for the init problem, if you can validate the warning is gone. If the tests blow up, that's a sign something else is wrong but we should know it now that the methods are guarded.

Scott Cantor 
November 6, 2017 at 9:53 PM

The bug is in the AbstractMetadataProviderParser class that auto-wraps the "root" MetadataResolver of the service in an instance of the class that's causing us trouble. That builder never gets the setInitMethod/setDestroyMethod pair called on it, so that's why the initialize doesn't happen.

Scott Cantor 
November 6, 2017 at 9:12 PM

Adding "if not init'd" checks to the resolve() methods triggers the expected test failures so the core issue here is the lack of a call to init(). Once that's done, the setId() will get taken care of.

Fixed

Details

Assignee

Reporter

Fix versions

Affects versions

Created November 6, 2017 at 7:14 PM
Updated November 6, 2017 at 11:51 PM
Resolved November 6, 2017 at 11:51 PM