ReloadableConfiguration

1 Spring and Resources
2 Reloadability
- 2.1 Programming a reloadable subsystem
- 2.2 Configuring the reloadable subsystem
- 2.3 Using the reloadable subsystem
- 2.4 Example Code
  - 2.4.1 Declaring the component with a service
  - 2.4.2 Using the Component

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 Resource has been implemented: the HTTPResource type.

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.shared.spring.service.AbstractServiceableComponent and net.shibboleth.shared.spring.service.ReloadableSpringService classes.

To make a subsystem reloadable, the implementation bean must extend AbstractServiceableComponent and implement getComponent() to return itself.

In practice, in most cases (attribute resolution and attribute filtering are the outliers) all the work will be done for you by ReloadableSpringService; You just need to define:

An (API) interface that defines the work you need.
An (Impl) class extending AbstractIdentifiableInitializableComponent and implementing this interface.

Configuring the reloadable subsystem

To configure a serviceable bean, instantiate a ReloadableSpringService, providing the class type of the subsystem bean (or the interface it implements) to the constructor, and a list of Spring resources in the serviceConfiguration property (which need to contain definitions for a bean of your impl type). Other properties which can be used to control reloading behavior include:

failFast
reloadCheckDelay
reloadtaskTimer

There are numerous examples in the internal file services-system.xml, including advanced examples (e.g. attribute resolver) 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.
Closing the component (via Java’s AutoCloseable interface).

It is vital that every call to getServiceableComponent() is matched by a call to unpinComponent() as these are essentially lock and unlock operations, but wrapping the component in a try-with-resources is generally the easiest way to guarantee this.

Example Code

Declaring the component with a service

<util:list = "myResourceList">
  <value>classpath:/the/name/for/your/serviuce/myservice-system.xml</value>
  <value>%{idp.home}/conf/myservice-conf.xml</value>
</util:list>

<bean id="the.name.for.your.service" parent="shibboleth.ReloadableService" 
        c:claz="path.to.your.YourInterface"
        p:serviceConfigurations-ref="myResourceList"
        p:failFast="%{whatever}"
        p:reloadCheckDelay="%{idp.service.nameidGeneration.checkInterval:PT0S}"/>

Using the Component

// theService is populated (in system context) from the bean called "the.name.for.your.service"

try (final ServiceableComponent<YourInterface> component = theService.getServiceableComponent()) {
  final YourInterface worker = component.getComponent();
  worker.doSomethingExciting(prc);
}