Programmatic Registration of Java Configuration Beans
Programmatic Registration of Java Configuration Beans
Migrating from XML configuration to Java configuration in Spring can be challenging sometimes. We take a look at a real-world example via Spring Security.
Join the DZone community and get the full member experience.
Join For FreeDownload Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.
I have been working on refactoring the Spring Security Calendar application from an XML configuration to a Java configuration.
In the migration, the is a DefaultService.java file that is using UserDetailsManager, which extends UserDetailsService:
DefaultService:
@Repository
public class DefaultCalendarService implements CalendarService {
...
private UserDetailsManager userDetailsManager;
@Autowired
public DefaultCalendarService(final EventDao eventDao,
final CalendarUserDao userDao,
final UserDetailsManager userDetailsManager) {
...UserDetailsManager:
public interface UserDetailsManager extends UserDetailsService {
...***************************
APPLICATION FAILED TO START
***************************
Description:
Parameter 2 of constructor in com.packtpub.springsecurity.service.DefaultCalendarService required a bean of type 'org.springframework.security.provisioning.UserDetailsManager' that could not be found.
Action:
Consider defining a bean of type 'org.springframework.security.provisioning.UserDetailsManager' in your configuration.The crux of the issue is that with Java configuration and @Autowired-driven configuration, the configuration initialization ordering does not allow for Security Objects to be initialized before other @Component’s.
There is a JIRA ticket already discussing this issue, and eluding to a possible fix in Spring Security 5. I created a custom WebSecurityConfigurerAdapter:
@Configuration
@EnableWebSecurity(debug = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {@Bean
@Override
public UserDetailsService userDetailsService() {
InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
manager.createUser(User.withUsername("user").password("password").roles("USER").build());
manager.createUser(User.withUsername("admin").password("admin").roles("USER", "ADMIN").build());
manager.createUser(User.withUsername("user1@example.com").password("user1").roles("USER").build());
manager.createUser(User.withUsername("admin1@example.com").password("admin1").roles("USER", "ADMIN").build());
return manager;
}The issue is that we actually needed a UserDetailsManager not a UserDetailsService, so I changed the return type to UserDetailsManager as seen:
@Bean
@Override
public UserDetailsManager userDetailsService() {
...Now we can successfully Autowire a UserDetailsManager into other @Components in our IoC.
Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat.
Like This Article? Read More From DZone
Published at DZone with permission of Mick Knutson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}