Extending CAS Configuration

Being a Spring Boot application at its core, designing and extending CAS configuration components very much comes down to the following guide some aspects of which are briefly highlighted in this document.

Configuration Components

This is the recommended approach to create additional Spring beans, override existing ones and simply inject your own custom behavior into the CAS application runtime.

Given CAS’ adoption of Spring Boot, most if not all of the old XML configuration is transformed into @Configuration components. These are classes declared by each relevant module that are automatically picked up at runtime whose job is to declare and configure beans and register them into the application context. Another way of thinking about it is, components that are decorated with @Configuration are loose equivalents of old XML configuration files that are highly organized where <bean> tags are translated to java methods tagged with @Bean and configured dynamically.

Design

To design your own configuration class, take inspiration from the following sample:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package org.apereo.cas.custom.config;

@Configuration("SomethingConfiguration")
@EnableConfigurationProperties(CasConfigurationProperties.class)
public class SomethingConfiguration {

    @Autowired
    private CasConfigurationProperties casProperties;

    @Autowired
    @Qualifier("someOtherBeanId")
    private SomeBean someOtherBeanId;

    @RefreshScope
    @Bean
    public MyBean myBean() {
        return new MyBean();
    }
} 

• The @Bean definitions can also be tagged with @RefreshScope to become auto-reloadable when the CAS context is refreshed as a result of an external property change.
• @Configuration classes can be assigned an order with @Order(1984) which would place them in an ordered queue waiting to be loaded in that sequence.
• To be more explicit, @Configuration classes can also be loaded exactly before/after another @Configuration component with @AutoConfigureBefore or @AutoConfigureAfter annotations.

Register

How are @Configuration components picked up? Each CAS module declares its set of configuration components as such, per guidelines laid out by Spring Boot:

• Create a src/main/resources/META-INF/spring.factories file
• Add the following into the file:

1
org.springframework.boot.autoconfigure.EnableAutoConfiguration=org.apereo.cas.custom.config.SomethingConfiguration

Overrides

What if you needed to override the definition of a CAS-provided bean and replace it entirely with your own?

This is where @Conditional components come to aid. Most component/bean definitions in CAS are registered with some form of @Conditional tag that indicates to the bootstrapping process to ignore their creation, if a bean definition with the same id is already defined. This means you can create your own configuration class, register it and the design a @Bean definition only to have the context utilize yours rather than what ships with CAS by default.

CAS Properties

The collection of CAS-provided settings are all encapsulated inside a CasConfigurationProperties component. This is a parent class that brings all elements of the entire CAS platform together and binds values to the relevant fields inside in a very type-safe manner. The configuration binding is typically done via @EnableConfigurationProperties(CasConfigurationProperties.class) on the actual configuration class.

If you wish to design your own and extend the CAS configuration file, you can surely follow the same approach with the @EnableConfigurationProperties annotation or use the good ol’ @Value.