FYI: https://github.com/apache/grails-core/pull/14891 is the PR that will restore the choice of using either Sitemesh3 or Sitemesh2 with Grails 7.
@Scott, given that this functionality makes 7 equivalent to what it was before the M4 and it's fully decoupled, do we need to resolve the Sitemesh3 issues immediately? I'm traveling next week, and would like to address the micronaut test apps & metadata issues since they're more critical to the Grails 7 final release. My hope is we could fix sitemesh3 related issues as time permits from working on the Grails 7 blockers. On Thu, Jul 3, 2025 at 6:32 PM James Daugherty <jdaughe...@apache.org> wrote: > FYI: I opened https://issues.apache.org/jira/browse/LEGAL-707 for the > license question. Although, struts used it up until last year, so I assume > it's acceptable. > > On 2025/07/02 11:38:52 James Daugherty wrote: > > Hi Everyone, > > > > I started investigating a ticket related to forwarding not working in a > > Grails controller on 7.0.0-M4. As part of that I made this discovery: > > > https://github.com/apache/grails-core/issues/14193#issuecomment-3017157073 > > It seems the DispatcherServlet from Spring is designed to handle > multiple > > calls methods that cause the response to render and close. The > dispatcher > > chooses the right one by the committed state of the response. > > > > From my investigation, the Sitemesh 3 implementation appears to use a > > filter to render its output after the DispatcherServlet is processed - so > > the response state is never committed. I think we could update the > > GrailsDispatcherServlet to handle the various scenarios that the > > DispatcherServlet handles, but I'm not sure this is practical for Grails > 7 > > given the delays we have already had. We would also be deviating from > how > > Spring MVC controllers are rendered and this logic doesn't appear that > > simple. Moreover, we still have several outstanding tickets related to > the > > sitemesh 3 upgrade: > > > > * Apr 2025 - https://github.com/apache/grails-core/issues/14193 - > > forwarding from a controller > > * Jan 2025 - https://github.com/apache/grails-core/issues/13988 - nested > > layouts > > * Feb 2005 - https://github.com/apache/grails-core/issues/14197 - $raw > in > > titles > > * Nov 2024 - https://github.com/apache/grails-core/issues/13849 - > layout by > > convention > > > > We have reached out to the developer of Sitemesh 3 on most of these > tickets > > (via ticket comments and direct slack messages over the past few months); > > we have yet to receive any work or progress on them. The oldest of which > is > > 8+ months old. I'm skeptical these can be finished in a reasonable time > > frame. > > > > > > Given the lack of support, the multiple issues found by users, and the > > current state of Grails 7 being delayed by these tickets, I would like to > > propose we revert back to Sitemesh 2.6.0. Assuming we confirm all of > these > > issues are fixed, we would only have the remaining license, asset plugin > > release, & ASF release related issues to fix before we could release > Grails > > 7. > > > > > > I have gone ahead and reverted back to Sitemesh 2.6.0 in the issue14193 > > branch (https://github.com/apache/grails-core/tree/issue14193). As > part of > > switching back to v2, I discovered the following is now fixed: > > * async rendering > > * async error handling > > * layout specified by a controller property > > * layout specified in controller property applied to a GSP that does not > > contain a root html tag > > > > It seems the sitemesh3 upgrade was performed during a time when the > project > > wasn't running all of its tests, so we are only now learning the scope of > > its impact. I think we can still be open to switching to Sitemesh 3 in > > Grails 8. Especially if we get the necessary support, but otherwise, we > > can continue with 2.x. > > > > Please note as part of this branch revert, I've also taken a closer look > at > > the Sitemesh licensing requirements and made a first pass being > compatible > > with the Sitemesh license. We'll still have to follow-up with ASF legal > to > > ensure we're compliant since the license is a derivative of the ASF > > license. > > > > -James > > >
