The GitHub Actions job "Groovy Snapshot Canary Build" on grails-core.git/feat/spring-application-builder has succeeded. Run started by GitHub user jdaugherty (triggered by jdaugherty).
Head commit for run: 9e8a018ccd8d1b2333c47c59580be8b1d4d42c14 / James Daugherty <[email protected]> Make GrailsAppBuilder hierarchies hold exactly one Grails application Builds on the 8.0.x fix that starts every context of a GrailsAppBuilder hierarchy with a GrailsApp (#16462), and settles what a hierarchy means for the Grails lifecycle, which keeps JVM-wide state: Holders, the initializing flag, the shutdown operations and the development watch. Exactly one context of a hierarchy is the Grails application. A context whose parent chain already holds a grailsApplication refuses to start as a second one. GrailsApplicationPostProcessor registers grailsApplication and pluginManager locally in every context and lends them to the parent, and takes the loan back in DisposableBean.destroy(), which Spring runs on a normal close and on a failed refresh alike, so a parent that outlives its Grails child holds nothing of it and another Grails child can start beneath it; a parent bean that injected the lent singletons is destroyed with them and recreated against the next loan, and the docs point parent beans at ObjectProvider instead. The contextHierarchyMember flag the builder sets becomes a public GrailsApp property, so a hierarchy assembled by hand can set it. No running address is reported for a context without a web server. Documented in a new "Building the Application" page and the what's new section, which replace the short section the fix added to "Executing the Application Class", and exercised by the second-application refusal and loan-return specs and by the web example's sibling-refusal spec. Report URL: https://github.com/apache/grails-core/actions/runs/36892129756 With regards, GitHub Actions via GitBox
