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, two other specialized Resources have been implemented, the SVNResource and the HTTPResource types.
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:
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
- Interrogating the component for the subsystem component (via
- Performing operations on the component.
- Unpinning the component. (via
It is vital that every call to
getServiceableComponent() is matched by a call to
unpinComponent() as these are essentially lock and unlock operations.