jdaugherty commented on issue #14193:
URL: https://github.com/apache/grails-core/issues/14193#issuecomment-3017157073
Further information on this ticket, the GrailsLayoutView from Grails 6.x is
what used to caused the response to be committed after the call to `forward`
was processed this code triggered on the layout view:
@Override
protected void renderTemplate(Map<String, Object> model,
GrailsWebRequest webRequest, HttpServletRequest request,
HttpServletResponse response) throws Exception {
boolean isCommitted = response.isCommitted() && (response
instanceof OutputAwareHttpServletResponse) &&
!((OutputAwareHttpServletResponse) response).isWriterAvailable();
if( !isCommitted ) {
Content content = obtainContent(model, webRequest,
request, response);
if (content != null) {
beforeDecorating(content, model, webRequest,
request, response);
switch (request.getDispatcherType()) {
case INCLUDE:
break;
case ASYNC:
case ERROR:
case FORWARD:
case REQUEST:
if(LOG.isDebugEnabled()) {
LOG.debug("Finding layout for request
and content" );
}
SpringMVCViewDecorator decorator =
(SpringMVCViewDecorator) groovyPageLayoutFinder.findLayout(request, content);
if (decorator != null) {
if(LOG.isDebugEnabled()) {
LOG.debug("Found layout. Rendering
content for layout and model {}", decorator.getPage(), model);
}
decorator.render(content, model,
request, response, webRequest.getServletContext());
return;
}
break;
}
PrintWriter writer = response.getWriter();
if(LOG.isDebugEnabled()) {
LOG.debug("Layout not applicable to response,
writing original content");
}
content.writeOriginal(writer);
if (!response.isCommitted()) {
writer.flush();
}
}
}
}
The writer.flush() call from processing the forward's layout would cause the
response to be committed, so further calls in the action would be detected as
not needing rendered. I'm assuming Sitemesh 3 now handles rendering the layout
here:
https://github.com/sitemesh/sitemesh3/blob/49c02e7246359cd2b4952d3f319f1a638430a477/sitemesh/src/main/java/org/sitemesh/webapp/SiteMeshFilter.java#L113
I'm not as familiar with the sitemesh 3 code but I assume it's being
rendered in the filter I mention above - which occurs after the dispatcher,
while before it would have occurred inside of the dispatcher. The dispatcher
appears to assume that the call to renderView() will commit the result. This
seems incompatible with sitemesh's approach.
@codeconsole can you give your thoughts on this one? Can you help clarify
where the rendering of sitemesh occurs? Is it actually in the filter? Can
this be moved to a "view" so that the dispatcher can work as it did before ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
