Application that depends upon spring-boot-starter-web and spring-boot-starter-jersey fails to start due to attempt to override requestContextFilter bean

[wilkinsona]

As reported in this question on Stack Overflow, an app that depends on both spring-boot-starter-web and spring-boot-starter-jersey will fail to start. It fails with the following output:

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

Description:

The bean 'requestContextFilter', defined in class path resource [org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/boot/autoconfigure/jersey/JerseyAutoConfiguration.class] and overriding is disabled.

Action:

Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true

There's, presumably, a bug or at least some unintended behaviour in 2.0 and perhaps 1.5 as well with the requestContextFilter bean being overridden. It fails hard on 2.1 due to bean overriding now being disabled by default.

[philwebb]

Looks like the condition is also wrong on the Jersey one:

@Bean
@ConditionalOnMissingBean
public FilterRegistrationBean<RequestContextFilter> requestContextFilter() {

That's similar to #14897

[wilkinsona]

The definition in WebMvcAutoConfiguration:

@Bean
@ConditionalOnMissingBean({ RequestContextListener.class,
		RequestContextFilter.class })
public static RequestContextFilter requestContextFilter() {
	return new OrderedRequestContextFilter();
}

The definition in JerseyAutoConfiguration:

@Bean
@ConditionalOnMissingBean
public FilterRegistrationBean<RequestContextFilter> requestContextFilter() {
	FilterRegistrationBean<RequestContextFilter> registration = new FilterRegistrationBean<>();
	registration.setFilter(new RequestContextFilter());
	registration.setOrder(this.jersey.getFilter().getOrder() - 1);
	registration.setName("requestContextFilter");
	return registration;
}

OrderedRequestContextFilter has an order of -105. The default order for Jersey's filter is 0, so the RequestContextFilter has an order of -1.

In Spring Boot 2.0, the bean from JerseyAutoConfiguration is overridden by the bean from WebMvcAutoConfiguration:

2018-11-08 12:48:09.965  INFO 63644 --- [           main] o.s.b.f.s.DefaultListableBeanFactory     : Overriding bean definition for bean 'requestContextFilter' with a different definition: replacing [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=org.springframework.boot.autoconfigure.jersey.JerseyAutoConfiguration; factoryMethodName=requestContextFilter; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/boot/autoconfigure/jersey/JerseyAutoConfiguration.class]] with [Root bean: class [org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=requestContextFilter; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter.class]]

As a result, if Jersey has been configured to use a filter and jersey.filter.order has been customised, it's possible for the request context filter to swap places with Jersey's filter. I'm not sure how much that matters as a Jersey-based app is unlikely to be using RequestContextHolder.

As things stand, WebMvcAutoConfiguration runs after JerseyAutoConfiguration. If we fix the bean override, the request context filter defined by JerseyAutoConfiguration will cause the one in WebMvcAutoConfiguration to back off. That will change its order from -105 to -1 which I think will adversely effect Spring MVC apps.

I wonder if we need the Jersey-specific RequestContextFilter at all? It was added in this commit which, unfortunately, does not explain why it's needed in a Jersey app. All of the JerseyAutoConfiguration…Tests pass without it. I am leaning towards living with the override in Boot 2.0 and removing the Jersey-specific RequestContextFilter in 2.1.x.

[wilkinsona]

We're going to remove Jersey's RequestContextFilter.

[gerdzhikov]

Hi, is there some workaround here?

[wilkinsona]

Yes. It is described in the answer to the Stack Overflow question that’s linked to above.

[kubapet]

I used the spring.main.allow-bean-definition-overriding=true WKA, but I am using spring-boot-starter-websocket an I m still not able to get the @MessageMapping working annotation inside of @Controller, it's being ignored while the other mappings work fine. Any ideas?

[wilkinsona]

@kubapet I can’t see any connection between this issue and @MessageMapping. Please ask any questions you may have on Stack Overflow. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.