The IdP makes significant use of spring resources (org.springframework.core.io.Resource
) and all configuration is via them.
As well as the usual slew of Spring provided Resources two other Resources have been implemented, the SVNResource and the HTTPResource.
Any subsystem which is configured via Spring may be made reloadable. This capability is provided by the AbstractServiceableComponent and ReloadableSpringService classes.
To make a subsystem reloadable, the implementation bean just has to extend AbstractServiceableComponent and implement getComponent() to return this
.
To configure a serviceable bean, configure a ReloadableSpringService, providing the Class of the subsystem bean (or an interface it implemements) as constructor and a list of Spring resources as the serviceConfiguration property. Other properties which can be specific are
For example:
<bean id="shibboleth.AttributeFilterService" class="net.shibboleth.idp.service.ReloadableSpringService"> <constructor-arg value="net.shibboleth.idp.attribute.filter.AttributeFilter"/> <property name="id" value="shibboleth.AttributeFilterService" /> <property name="serviceConfigurations"> <util:list> <value>file://${idp.home}/conf/attribute-filter.xml</value> </util:list> </property> <property name="failFast" value="${idp.service.attribute.filter.failFast}" /> <property name="reloadCheckDelay" value="${idp.service.attribute.filter.checkInterval}" /> <property name="reloadTaskTimer" ref="shibboleth.TaskTimer" /> </bean> |
Using the subsystem consists of
It is vital that every call to getServiceableComponent is matched by a call to unpinComponent()