Table of Contents |
---|
Spring and Resources
The IdP makes significant use of spring resources For its self-contained subsystems, the IdP programmatically creates and manages its own Spring application contexts by loading configuration resources. The Spring Resource interface (org.springframework.core.io.Resource
) and all configuration is via themis used to manage access to configuration material.
As well as the usual slew of Spring-provided Resources Resource types, two other specialized Resources have been implemented, the SVNResource and the HTTPResourcetypes.
Reload
Any subsystem which is configured via Spring
Reloadability
Programming a reloadable subsystem
Any of the subsystems that explicitly manage their own Spring configurations may be made reloadable. This capability is provided by the net.shibboleth.ext.spring.service.AbstractServiceableComponent and net.shibboleth.ext.spring.service.ReloadableSpringService classes.
...
To make a subsystem reloadable, the implementation bean just has to must extend AbstractServiceableComponent and implement getComponent()
to to return this
itself.
Configuring the reloadable subsystem
To configure a serviceable bean, configure instantiate a ReloadableSpringService, providing the Class class type of the subsystem bean (or an interface it implemements) as to the constructor, and a list of Spring resources as the in the serviceConfiguration
property. Other properties which can be specific areused to control reloading behavior include:
failFast
reloadCheckDelay
reloadtaskTimer
For example:
Code Block | ||||
---|---|---|---|---|
| ||||
<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 reloadable subsystem.
Using the subsystem consists ofThere are numerous examples in system/conf/services-system.xml, including advanced examples that demonstrate how to dynamically supply an implementation class that implements the desired interface after configuring the Spring context.
Using the reloadable subsystem
Using a subsystem requires:
- Interrogating the ReloadableSpringService for the current Serviceable Component for serviceable component in the subsystem (via
getServiceableComponent()
) - Interrogating the component for the subsystem component (via
getComponent()
) - Performing operations on the operationcomponent.
- Unpinning the component. (via #
unpinComponent()
)
It is vital that every call to to getServiceableComponent()
is matched by a call to unpinComponent()
as these are essentially lock and unlock operations.