spring-boot: Suppress "Circular view path [error]" error message

  1. clone simple project: https://github.com/stepancheg/spring-boot-whitelabel

project contains controller with function

@RequestMapping("/throw")
@ResponseBody
public String t() {
    throw new RuntimeException();
}

and project calls

System.setProperty("error.whitelabel.enabled", "false");

before main.

  1. run main class (demo.Application)
  2. point browser to http://localhost:8080/throw

Browser displays white page. Expecting something more sensible. Tomcat default error handler would be perfect.

Using spring-boot 1.2.0.RC2.

About this issue

  • Original URL
  • State: open
  • Created 10 years ago
  • Comments: 17 (8 by maintainers)

Most upvoted comments

@wilkinsona Sorry to dig up an old issue. But we have been seeing the same thing in our setup. I suppose it is a bit of a niche issue, since not many people actually turn off the default whitelabel behaviour, or just implement their own error view right away.

Much like the original issue report we have server.error.whitelabel.enabled=false and a @Controller throwing a RuntimeException. This is with spring-boot 1.5.19 and embedded tomcat container.

On the frontend, you will indeed get a normal Tomcat error page. In the backend a nasty error will be logged. javax.servlet.ServletException: Circular view path [error]: would dispatch back to the current handler URL [/error] again. Check your ViewResolver setup! (Hint: This may be the result of an unspecified view, due to default view name generation.)

This is a majorly confusing error, although the documentation (https://docs.spring.io/spring-boot/docs/1.5.19.RELEASE/reference/html/howto-actuator.html) seems correct in mentioning that:

Set server.error.whitelabel.enabled=false to switch the default error page off which will restore the default of the servlet container that you are using. Note that Spring Boot will still attempt to resolve the error view so you’d probably add you own error page rather than disabling it completely.

It is ErrorPageCustomizer in ErrorMvcAutoConfiguration that actually registers an ErrorPage even though server.error.whitelabel.enabled is set to false.

In my opinion, registering the ErrorPage at that point should not be done by default, but maybe made optional. It feels as if two autoconfiguration things have been mixed, which leads to a confusing error being logged in the end.

  • Maybe with a property (server.error.register-default-error-page), by default true to keep backwards compatibility? Which allows turning off the registration of ErrorPage.
  • Maybe with a smart bean check on beanName “error”, which would’t exist because WhitelabelErrorViewConfiguration wouldn’t have been handled, but could exist if you have defined your own error view.
  • Make ErrorPageCustomizer @ConditionalOnMissingBean ? So you can define your own empty implementation?

At the moment I use a hacky BeanPostProcessor to achieve the “wanted” behaviour (code for spring boot 2).

@Component
public class RemoveErrorPages implements BeanPostProcessor, EnvironmentAware {
    private Environment environment;

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if( bean instanceof AbstractConfigurableWebServerFactory) {
            if( "false".equals( environment.getProperty("server.error.whitelabel.enabled") ) ) {
                ((AbstractConfigurableWebServerFactory) bean).getErrorPages().clear();
            }
        }
        return bean;
    }

    @Override
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }
}

Of course using

spring:
  autoconfigure:
    exclude: 'org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration'

achieves the same.

The behaviour is also still present in Spring Boot 2.1.3.RELEASE so a fix for the confusing error message might still be needed. All configuration changes seem like a bit of a hack for fixing a confusing error message.

If you’d like a test project, I have one available to upload right away.

Thoughts?