Page Comparison

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

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:

<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:

1. Interrogating the ReloadableSpringService for the current Serviceable Component for serviceable component in the subsystem (via getServiceableComponent())
2. Interrogating the component for the subsystem component (via getComponent())
3. Performing operations on the operationcomponent.
4. 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.