The GitHub Actions job "CI" on grails-core.git/fix/gsp-spring-boot-standalone-8.0.x has succeeded. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: 5f11919ad4d70cc7ebf17a3cb4d430257a71b49e / Scott Murphy Heiberg <[email protected]> Let Spring Boot's error page render in a standalone application Any error or 404 a browser asked for ended in the container's own error page, with "Circular view path [error]" in the log. Boot renders its error page through the view named error, and the GSP view resolver is asked first. With no error.gsp and JSP views on, its fallback returned a JSTL view for error without checking that any such JSP exists; that view forwarded to /error, the URL being handled, and the container refused the loop. A client sending no Accept header gets Boot's JSON body instead, which is why no test saw it. The resolver GspAutoConfiguration contributes now falls back to a JSP only where the servlet context has one, and otherwise answers nothing, leaving the name to the resolvers after it - Boot's error page among them. A real JSP resolves as before, so the example's JSP rendering is still decorated by its layout. The check lives in a resolver used only by the standalone module. The shared GroovyPageViewResolver is unchanged, so a Grails application with JSTL present - where its errors are routed by URL mappings, never through Boot's error controller - keeps the fallback it has, including for a JSP that exists only as a precompiled servlet mapping with no resource behind it. ErrorPageTest in the example requests an unmapped path with Accept: text/html and gets Boot's page with a 404; StandaloneGroovyPageViewResolverSpec covers both branches through resolveViewName. Both fail with the check reverted. The guide page lists spring.gsp.jspEnabled with what it now does. Found by Mattias Reichel in review of #16184. Report URL: https://github.com/apache/grails-core/actions/runs/34873896438 With regards, GitHub Actions via GitBox
