@groovy.transform.CompileStatic
@org.springframework.boot.autoconfigure.AutoConfiguration
@org.springframework.boot.autoconfigure.AutoConfigureAfter(name: org.springframework.boot.webmvc.autoconfigure.DispatcherServletAutoConfiguration)
@org.springframework.boot.autoconfigure.AutoConfigureBefore(name: org.sitemesh.autoconfigure.SiteMeshViewResolverAutoConfiguration)
@org.springframework.boot.autoconfigure.condition.ConditionalOnClass(value: SiteMeshViewResolverBeanPostProcessor)
@org.springframework.boot.autoconfigure.condition.ConditionalOnProperty(name: sitemesh.integration, havingValue: view-resolver, matchIfMissing: true)
class Sitemesh3AutoConfiguration
extends java.lang.Object

Registers the Grails SiteMesh 3 integration beans ahead of the upstream auto-configuration: the Sitemesh3ViewResolverDefinitionPostProcessor (which rewrites the jspViewResolver definition into the decorating GrailsSiteMeshViewResolver), the GrailsSiteMeshViewResolverBeanPostProcessor, the CaptureAwareContentProcessor (contentProcessor) and the Sitemesh3LayoutFinder (decoratorSelector).

The definition-level rewrite is what applies decoration: because it acts on the bean definition, the decorating resolver is what gets instantiated no matter how early a consumer forces the lazy jspViewResolver into existence (see Sitemesh3ViewResolverDefinitionPostProcessor, the Grails implementation of upstream's bean-definition wrap mode). The bean post-processor is the fallback tier: it decorates a jspViewResolver registered as an instance rather than a definition. Upstream's post-processor never re-wraps a resolver that is already a SiteMeshViewResolver, so the two tiers cannot double-decorate.

Upstream's SiteMeshViewResolverAutoConfiguration declares its beans with @ConditionalOnMissingBean guards. By scheduling this configuration first (via AutoConfigureBefore) the Grails implementations are registered before those guards are evaluated, so the upstream defaults back off cleanly rather than being registered and then overridden after the fact. The two post-processors here cover all of upstream's registrations by type: the definition post-processor preempts the bean-definition mode bean, and the bean post-processor preempts both the wrap-all and bean-instance mode beans.

The contentProcessor and decoratorSelector beans drive view decoration, which is only meaningful when Spring MVC is resolving views, so they are gated on a DispatcherServlet being present. This keeps them out of the lightweight unit-test contexts built by grails-testing-support, which have no dispatcher servlet — and because the definition post-processor only rewrites jspViewResolver when both of those beans are registered, it keeps decoration out of such contexts too.