Spring and 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
) is used to manage access to configuration material.
As well as the usual slew of Spring-provided Resource types, one other specialized Resources has been implemented the HTTPResource types.
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 must extend AbstractServiceableComponent and implement getComponent()
to return itself.
Configuring the reloadable subsystem
To configure a serviceable bean, instantiate a ReloadableSpringService, providing the class type of the subsystem bean (or an interface it implemements) to the constructor, and a list of Spring resources in the serviceConfiguration
property. Other properties which can be used to control reloading behavior include:
failFast
reloadCheckDelay
reloadtaskTimer
There 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 in the subsystem (via
getServiceableComponent()
) - Interrogating the component for the subsystem component (via
getComponent()
) - Performing operations on the component.
- Unpinning the component. (via
unpinComponent()
)
It is vital that every call to getServiceableComponent()
is matched by a call to unpinComponent()
as these are essentially lock and unlock operations.