Rework ErrorController now that getErrorPath() is unused and server.error.path must be used to configure the error path

[brucebrit]

Spring boot: 2.2.2
IDE: Spring Tool Suite

One of the ways to create a custom error page is to create a controller class that implements ErrorController. By overriding the getErrorPath() method and returning /error, I am able to return the expected my custom error page (located at resources/templates/customError.html).

But when I return another path, other than /error, I get the following error:

This localhost page can’t be found. No webpage was found for the web address: http://localhost:8080/bruce

Why is that so.

@Controller
public class MyErrorController implements ErrorController{

 // @RequestMapping("/error")
    @RequestMapping("/error1")
    public String handleError() {
        return "customError";
    }

	@Override
    public String getErrorPath() {

        //return "/error"; 
        return "/error1"; 
    }
}

Interestingly, I have done another experiment. The getErrorPath() returns /error1 , but I change the RequestMapping annotation to @RequestMapping("/error"), and that really return customError.html. This seems to imply that the path return by getErrorPath() is ignored.

[philwebb]

I have a feeling that the interface is unnecessary since Spring Boot 2.0, but I need to double check. I think that setting the server.error.path property is now the only way to customize the actual error path.

If I remember correctly, we used to use ErrorController to allow us to configure security, but we substantially simplified that in Spring Boot 2.0.

[brucebrit]

Hi, thanks for the response.
If that is the case, do we still need to implements ErrorController class, since server.error.path in the properties file is sufficient to achieve what we want.

[philwebb]

I don't think so, but I've not had time to confirm for sure yet.

[wilkinsona]

We don't call getErrorPath() anywhere, however implementing ErrorController is required at the moment to cause the auto-configuration of Boot's BasicErrorController to back off:

spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/web/servlet/error/ErrorMvcAutoConfiguration.java

Lines 106 to 112 in 2725264

	@Bean
	@ConditionalOnMissingBean(value = ErrorController.class, search = SearchStrategy.CURRENT)
	public BasicErrorController basicErrorController(ErrorAttributes errorAttributes,
	ObjectProvider<ErrorViewResolver> errorViewResolvers) {
	return new BasicErrorController(errorAttributes, this.serverProperties.getError(),
	errorViewResolvers.orderedStream().collect(Collectors.toList()));
	}

I'm not exactly sure what we should do here. An ErrorController marker interface with no methods feels like a bit of a smell, but it does provide a way of identifying the user's error controller and getting the auto-configured one to back off. I can't really think of a better alternative.

[wilkinsona]

For 2.3.x we could deprecate getErrorPath() and make it a default method so that it doesn't have to be implemented.

[scottfrederick]

ErrorController is currently a @FunctionalInterface. We can't add a default implementation for getErrorPath() without removing @FunctionalInterface, which could break backward compatibility if users are creating lambda expressions using ErrorController.

[siller174]

@scottfrederick After 1caca6e we can't build projects with "-Werror" flag, because we must implement getErrorPath(), but method is deprecated

getErrorPath() in org.springframework.boot.web.servlet.error.ErrorController has been deprecated

Compilation failure [ERROR] /.../.../CustomErrorController.java: warnings found and -Werror specified

version 2.3.0.RELEASE

[wilkinsona]

@siller174 If you want to compile with -Werror you should suppress the deprecation warning using @SuppressWarnings.

[yhojann-cl]

I have a feeling that the interface is unnecessary since Spring Boot 2.0, but I need to double check. I think that setting the server.error.path property is now the only way to customize the actual error path.

If I remember correctly, we used to use ErrorController to allow us to configure security, but we substantially simplified that in Spring Boot 2.0.

But ErrorController require the deprecated getErrorPath function. When remove says:

CustomErrorController is not abstract and does not override abstract method getErrorPath() in ErrorController

What is the best alternative?

[scottfrederick]

@WHK102 If you provide your own ErrorController implementation, you'll need to implement the getErrorPath method. It can return null or anything you want it to, the return value will be ignored. It's unfortunate, but it's the best option without breaking backward-compatibility of the API.

[xwpongithub]

@wilkinsona According to this configuration, how to return json instead of a template path when a 404 error occurs

[wilkinsona]

@xwpongithub Sorry, I don't see the connection between this issue and your question. Also, as mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements. Please use Stack Overflow or Gitter for questions like this.

[nkavian]

@wilkinsona I'm saddened by this. The maven-compiler-plugin keeps reporting the deprecation with and without SuppressWarnings, so I can't get it to stop. Eclipse doesn't complain, just maven. I take pride in having clean code and this sucks as my only unresolvable item. Using Spring Boot 2.4.4. when will this deprecation be fully removed?

[scottfrederick]

@nkavian Per the project policy, the method that was deprecated in 2.3.0 has been removed for the upcoming 2.5.0 release.

[wilkinsona]

@nkavian I'm not sure why the compiler that Maven's using (typically javac) wouldn't respect the suppression of deprecation warnings. Until you've upgraded to Boot 2.5, you may also want to try marking your own implementation as @Deprecated.

[nkavian]

Wow, that trick worked! Thanks.

[brsolomon-deloitte]

@nkavian Per the project policy, the method that was deprecated in 2.3.0 has been removed for the upcoming 2.5.0 release.

No mention of this in 2.3 release notes.

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.3-Release-Notes

[wilkinsona]

Thanks, @brsolomon-deloitte. I've updated the release notes to list the deprecation.

[brsolomon-deloitte]

Thanks for doing that @wilkinsona . I have been tasked with bringing an old Java lib kicking and screaming into 2023, so I've learned my lesson here to compile strict and turn deprecation warnings into errors to begin with :)