The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.

ReloadableConfiguration

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:

  1. Interrogating the ReloadableSpringService for the current serviceable component in the subsystem (via getServiceableComponent())

  2. Interrogating the component for the subsystem component (via getComponent())

  3. Performing operations on the component.

  4. 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.