Expose bean setters in @Configuration used by @EnableWebFluxSecurity

[jgrandja]

Fixes gh-6624

[sdeleuze]

After having a look to the implementation, I am wondering if we could not avoid this ApplicationContext and just leverage regular bean autowiring which would be conceptually cleaner IMO.

[jgrandja]

Good point - I reverted that change. I applied the same for ServerHttpSecurityConfiguration.beanFactory as well so reverted that as well.

FYI, I did a force-push to start fresh.

[rwinch]

I'm curious why the functional stuff is leveraging a class named @Configuration that contains @Autowired on it as well. This doesn't seem intuitive to me since the functional stuff is suppose to be free of @Configuration. Even if the annotations aren't processed, it isn't intuitive to be leveraging a class named ServerHttpSecurityConfiguration. I wonder if we should have the functional stuff use ServerHttpSecurity directly. If it needs the logic in ServerHttpSecurityConfiguration, perhaps we should extract out another class that can be used by both @Configuration and the functional code?

I think we should name the methods setXYZ since the return value is null. Alternatively, I'd be open to returning this and keeping the methods named as is.

[jgrandja]

I also feel that it can be confusing to a user looking at this code and wondering why is a @Configuration class being used by a functional API in it's implementation.

I agree with @rwinch, it might be the right direction to take as far as

If it needs the logic in ServerHttpSecurityConfiguration, perhaps we should extract out another class that can be used by both @Configuration and the functional code?

[sdeleuze]

@rwinch In Spring Fu case, the annotations are indeed not used, but I would like to leverage these classes to create the same infra via function bean registration like I do for Spring Boot, Spring MVC or WebFlux configuration. If the principle is not clear, please have a look to https://github.com/spring-projects/spring-fu/tree/master/autoconfigure-adapter. These initializers are leveraged by Kofu and Jafu DSLs. From my understanding, these configuration classes are used in a functional way and are needed to make it possible to have a ServerHttpSecurity instance. If my understanding is wrong, please let me know.

[jgrandja]

@sdeleuze I spoke with @rwinch and we came up with the following approach:

ServerHttpSecurityConfiguration configuration = new Configurer()
		.adapterRegistry(adapterRegistry)
		.authenticationManager(authenticationManager)
		.reactiveUserDetailsService(reactiveUserDetailsService)
		.passwordEncoder(passwordEncoder)
		.userDetailsPasswordService(userDetailsPasswordService)
		.configuration();

Does this work for you?

[jgrandja]

@sdeleuze As per our discussion, you don't require a fluent configuration API so I've provided you standard setters with package-private access and moved @Autowired from field to these new setters.

[sdeleuze]

That's exactly what I need for programmatic use, and I like how it improves configuration testability, so 👍 from me.