Spring Formatters have been not registered when some class extends WebSecurityConfigurerAdapter

[jcagarcia]

The desired steps to a valid Formatters registration are:

1. First of all, the method addWebMvcConfigurers located in WebMvcConfigurationComposite should registrate all the web configurers. That includes the formatters.
2. After that, when some component needs to @Autowired a ConversionService instance, the method mvcConversionService located in WebMvcConfigurationSupport obtains a ConversionService instance and register all the existing formatters on it before return the instance.

However, if a @Configuration class extends the WebSecurityConfigurerAdapter abstract class, some component is trying to @Autowired a ConversionService instance before the formatters have been registered in the Spring context, so the addFormatters method doesn't include any formatters on it.

I've just created the following proof of concept that uses Spring Boot to reproduce this issue:

https://github.com/jcagarcia/proofs/tree/master/spring-security-and-formatters

If you execute this proof of concept using the mvn compile spring-boot:run command, you could check that the Create Pets view shows an enum value without apply the conversion to String.

Seems like the component that requires the ConversionService instance is the ContentNegotiation that is beeing @Autowired in the WebSecurityConfigurerAdapter.

A simple work-around is to @Override the setContentNegotiationStrategy method in our SecurityConfiguration class without include the @Autowired annotation. (The proof of concept includes this work-around commented)

After that, execute this proof of concept again using the mvn compile spring-boot:run command and you could check that the Create Pets view shows an enum value with a valid format applied.

I think this is not the best solution because the ContentNegotiationStrategy is not beeing @Autowired anymore.

I've just created a question in StackOverflow to obtain some answer:

http://stackoverflow.com/questions/42086046/spring-formatters-have-been-not-registered-when-some-class-extends-websecurityco

Best Regards,

[jcagarcia]

Also, I've just created a new issue in the Spring Framework JIRA

Check out https://jira.spring.io/browse/SPR-15239

[franrevoredo]

I've had the same problem, this bug prevented the select fields from my html5 views from beign populated with select2.

[cordin]

Any chance to take a look at this issue? It happens in the projects generated with Roo 2.0 RC1 and it would be nice to be able to solve it before the final release, without using the @jcagarcia workaround.

[rwinch]

Thanks for the ping.

Everything I see points to an ordering issue with Spring Boot. I don't think there is anything Spring Security can do. Spring Security needs the ContentNegotiationStrategy so we cannot disable the lookup.

As Rossen alludes to on the Spring Framework ticket, I think Boot needs to change some ordering of the configuration. Specifically, it may be valuable to break out the ContentNegotiationStrategy to load earlier.

@wilkinsona What are your thoughts?

[wilkinsona]

It's been a while, but my recollection of the issue is that it could easily be triggered by a user's own configuration as well as by the current arrangement in Spring Boot. My concern, therefore, was that a fix in Spring Boot may only be a point solution. I had wondered if a more general purpose change in Spring Security may be possible.

[rwinch]

Thanks for the fast response @wilkinsona I don't think there really is anything Spring Security can do.

Spring Security needs that Bean and needs it eagerly to properly build the objects. If we did a delayed lookup from the ApplicationContext we would not find the ContentNegotiationStrategy and default it to the HeaderContentNegotationStrategy but this would not be the desired behavior.

These sort of ordering issues creep up in Java Configuration and typically the place that it needs fixed is in the offending configuration. Therefore if a user had this issue they would be required to update their configuration in the same way.

I'm not really sure how this would be triggered in a non-boot scenario because as far as I know Boot is the only way to have delayed loading of beans with the autoconfigurations. Perhaps you can help me to understand how this would occur without Boot.

[wilkinsona]

These sort of ordering issues creep up in Java Configuration and typically the place that it needs fixed is in the offending configuration.

Agreed. What I don't think we agree on, yet, is where that offending configuration is. I had thought that Spring Security could use @Lazy to prevent it from eagerly creating the ContentNegotiationStrategy.

I'm not really sure how this would be triggered in a non-boot scenario because as far as I know Boot is the only way to have delayed loading of beans with the autoconfigurations. Perhaps you can help me to understand how this would occur without Boot.

Auto-configuration doesn't delay the loading of any beans, it just orders the configuration classes such that auto-configured bean defintions are processed after all of a user's bean definitions. In other words, any configuration arrangement that exists in Boot could be created in a non-Boot application.

Here's a significantly smaller application that reproduces the problem:

@SpringBootApplication
public class Security4202Application {

	public static void main(String[] args) {
		ConversionService conversionService = SpringApplication.run(Security4202Application.class, args)
				.getBean(ConversionService.class);
		conversionService.convert("some input", Thing.class);
	}

	@JsonComponent
	static class ThingDeserializer extends JsonDeserializer<Thing> {

		public ThingDeserializer(ConversionService conversionService) {
		}

		@Override
		public Thing deserialize(JsonParser p, DeserializationContext ctxt)
				throws IOException, JsonProcessingException {
			return null;
		}

	}

	@Configuration
	static class MvcConfiguration extends WebMvcConfigurerAdapter {

		@Override
		public void addFormatters(FormatterRegistry registry) {
			registry.addFormatter(new Formatter<Thing>() {

				@Override
				public String print(Thing object, Locale locale) {
					return "formatted thing";
				}

				@Override
				public Thing parse(String text, Locale locale) throws ParseException {
					return new Thing();
				}

			});
		}

	}

	@Configuration
	static class SecurityConfiguration extends WebSecurityConfigurerAdapter {

	}

	static class Thing {

	}

}

When run, it should throw an exception indicating that the was no converter available for String to Thing. Interestingly, if we strip out Spring Security (by removing SecurityConfiguration), we can see that the early initialisation of ContentNegotiationStrategy that it triggers was masking a dependency cycle:

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  security4202Application.ThingDeserializer defined in file [/Users/awilkinson/dev/workspaces/spring/spring-boot/1.5.x/security-4202/target/classes/com/example/Security4202Application$ThingDeserializer.class]
↑     ↓
|  org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$EnableWebMvcConfiguration
↑     ↓
|  org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter
↑     ↓
|  org.springframework.boot.autoconfigure.web.HttpMessageConvertersAutoConfiguration
↑     ↓
|  mappingJackson2HttpMessageConverter defined in class path resource [org/springframework/boot/autoconfigure/web/JacksonHttpMessageConvertersConfiguration$MappingJackson2HttpMessageConverterConfiguration.class]
↑     ↓
|  jacksonObjectMapper defined in class path resource [org/springframework/boot/autoconfigure/jackson/JacksonAutoConfiguration$JacksonObjectMapperConfiguration.class]
└─────┘

The cycle happens because the ThingDeserializer depends on the conversion service. The conversion service is produced by Spring MVC. Via Jackson and the Jackson HTTP message converter, the ThingDeserializer is required for the configuration of Spring MVC's message converters. This means that ThingDeserializer consumes the conversion service but also needs to be created so that Spring MVC can be initialized and can create the conversion service.

In short, injecting theConversionService into a JsonComponent or into anything involved with HTTP message conversion is very likely to create a dependency cycle. I'm not sure what, if anything could/should be done in Spring Boot to break this cycle. One obvious step outside of Boot would be to mark the ConversionService dependency in the JsonComponent as @Lazy.

I think it would also be beneficial to change Spring Security so that it doesn't trigger eager initialisation of the ContentNegotiationManager. This would stop it from masking the more obvious underlying problem.

[rwinch]

Thanks for the additional details @wilkinsona!

Perhaps I am mistaken, but I don't think I am getting the same result when removing the Security Configuration. When I remove the Security Configuration from the sample, the error goes away completely. It sounded as though you were getting an error of a circular bean dependency. I am using Boot 1.5.3.RELEASE. Perhaps this is a game of chance with the order components are getting scanned on our different systems?

Another thing I noticed is that if I replace the Security Configuration with the following, I also experience the ConverterNotFoundException.

@Autowired
ContentNegotiationStrategy contentNegotiationStrategy;

[wilkinsona]

@rwinch When you say "the sample" in your comment above, are you referring to Security4202Application that I wrote or the app provided by @jcagarcia?

[rwinch]

@wilkinsona Sorry for being unclear. I am referring to Security4202Application that you provided.

[wilkinsona]

That's a strange one. I have seen a few occasions in the past where the Framework isn't deterministic and things end up running in a different order causing sometimes dramatically different behaviour. I'd guess, and it is only a guess, that this is one of those cases.

[MrNghia123]

I have the same problem.