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 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 @AutoConfiguration 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 @AutoConfiguration 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

package org.apereo.cas.custom.config;

@AutoConfiguration
@EnableConfigurationProperties(CasConfigurationProperties.class)
public class SomethingConfiguration {
    @RefreshScope(proxyMode = ScopedProxyMode.DEFAULT)
    @Bean
    public MyBean myBean(
        @Qualifier("someOtherBeanId")
        final SomeBean someOtherBeanId,
        final CasConfigurationProperties casProperties) {
        return new MyBean();
    }
} 

• The @Bean definitions can also be tagged with @RefreshScope(proxyMode = ScopedProxyMode.DEFAULT) to become auto-reloadable when the CAS context is refreshed as a result of an external property change.
• @AutoConfiguration 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 Build & Beyond

Note that compiling configuration classes and any other piece of Java code that is put into the CAS Overlay may require additional CAS modules and dependencies on the classpath. You will need to study the CAS codebase and find the correct modules that contain the components you need, such as CasConfigurationProperties and others.

Register

How are @AutoConfiguration 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/org.springframework.boot.autoconfigure.AutoConfiguration.imports file
• Add the following into the file:

1

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.

Bean Names

To correctly define a conditional Bean, you generally need to make sure your own bean definition is created using the same name or identifier as its original equivalent. It is impractical and certainly overwhelming to document all runtime bean definitions and their identifiers. So, you will need to study the CAS codebase to find the correct configuration classes and bean definitions to note their name.

Feature Toggles

Please see this guide to learn more.

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.

Prefix Notation

Note that all CAS-provided settings exclusively begin with the prefix cas. Other frameworks and packages upon which CAS depends may present their own configuration naming scheme. Note the difference.

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.