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 FreeTake 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.
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.
Learn how the Actor model provides a simple but powerful way to design and implement reactive applications that can distribute work across clusters of cores and servers. Brought to you in partnership with Lightbend.
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 }}