Unlike previous versions, CAS 5 attempts to automate all required Spring Webflow changes on a per-module basis. In this new model, all one should have to do is to declare the appropriate module in the build script…and voilà! CAS will take care of the rest.
If you wish to learn how that is done internally and furthermore, how you may take advantage of the same approach to extend CAS webflows and introduce your own, this is the right post for you.
This tutorial specifically requires and focuses on:
5.3.x
This post might equally apply to CAS 5.2.x
. YMMV. To learn the same answers with CAS 5.0.x
, please see this post.
Every CAS module that needs to dynamically augment the Spring Webflow routes simply takes on the following form:
package com.example.cas;
public class SomethingWebflowConfigurer extends AbstractCasWebflowConfigurer {
public SomethingWebflowConfigurer(final FlowBuilderServices flowBuilderServices,
final FlowDefinitionRegistry loginFlowDefinitionRegistry,
final ApplicationContext applicationContext,
final CasConfigurationProperties casProperties) {
super(flowBuilderServices, loginFlowDefinitionRegistry, applicationContext, casProperties);
}
@Override
protected void doInitialize() throws Exception {
final Flow flow = super.getLoginFlow();
// Magic happens; Call 'super' to see what you have access to...
}
}
CAS modules register their WebflowConfigurer
instances in @Configuration
classes:
package com.example.cas;
@Configuration("SomethingConfiguration")
public class SomethingConfiguration implements CasWebflowExecutionPlanConfigurer {
@Autowired
@Qualifier("loginFlowRegistry")
private FlowDefinitionRegistry loginFlowDefinitionRegistry;
@Autowired
private FlowBuilderServices flowBuilderServices;
@Autowired
private ApplicationContext applicationContext;
@Autowired
private CasConfigurationProperties casProperties;
@ConditionalOnMissingBean(name = "somethingWebflowConfigurer")
@Bean
public CasWebflowConfigurer somethingWebflowConfigurer() {
return new SomethingWebflowConfigurer(flowBuilderServices, loginFlowDefinitionRegistry,
applicationContext, casProperties);
}
@Override
public void configureWebflowExecutionPlan(final CasWebflowExecutionPlan plan) {
plan.registerWebflowConfigurer(somethingWebflowConfigurer());
}
}
Note that each CasWebflowConfigurer
implementation may be assigned a specific order which is a numeric weight that determines its execution position once webflow auto-configuration kicks into action.
Next, we just need to ensure that CAS is able to pick up our special configuration. To do so, create a src/main/resources/META-INF/spring.factories
file and reference the configuration class in it as such:
org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.example.cas.SomethingConfiguration
…and that should be it.
CAS itself handles Spring Webflow changes related to its first-class features by default automatically. That strategy equally applies, should you need to write your own configurers if you absolutely need to. Be sure to take extra as accidents may happen. What if you have two WebflowConfigurer
s who all decide to inject actions and state into the same Spring Webflow areas? What if multiple WebflowConfigurer
s are competing to set themselves up as starting points of the CAS webflow? Who wins, who mourns?
Indeed, these are questions you ought to be thinking about as a developer. With power comes responsibility.
That’s all.
Monday-Friday
9am-6pm, Central European Time
7am-1pm, U.S. Eastern Time
Monday-Friday
9am-6pm, Central European Time