This is an automated email from the ASF dual-hosted git repository.
jamesbognar pushed a commit to branch docs
in repository https://gitbox.apache.org/repos/asf/juneau.git
The following commit(s) were added to refs/heads/docs by this push:
new 0eb095f04b docs: renderer ordering subsection, view-module
typed-handler notes, release notes (TODO-96)
0eb095f04b is described below
commit 0eb095f04b54e9761ee0dd5e4ce581c0f589ff5f
Author: James Bognar <[email protected]>
AuthorDate: Wed May 27 12:54:44 2026 -0400
docs: renderer ordering subsection, view-module typed-handler notes,
release notes (TODO-96)
Co-authored-by: Cursor <[email protected]>
---
pages/release-notes/9.5.0.md | 36 ++++++++++++++++++++++++++++
pages/topics/10.14d.JspViewSupport.md | 22 ++++++++---------
pages/topics/10.14e.ThymeleafViewSupport.md | 18 +++++++-------
pages/topics/10.14f.MustacheViewSupport.md | 18 +++++++-------
pages/topics/10.14g.FreemarkerViewSupport.md | 19 +++++++--------
pages/topics/10.25.ResponseProcessors.md | 29 ++++++++++++++++++++++
6 files changed, 102 insertions(+), 40 deletions(-)
diff --git a/pages/release-notes/9.5.0.md b/pages/release-notes/9.5.0.md
index cc38866b6f..d890634825 100644
--- a/pages/release-notes/9.5.0.md
+++ b/pages/release-notes/9.5.0.md
@@ -2227,6 +2227,42 @@ String name
### juneau-rest-server
+#### `View`-returning `@RestOp` methods now reach their renderer automatically
(TODO-96)
+
+Response processors implementing the new `ViewRenderer` marker interface are
automatically
+positioned before catch-all processors (`CatchAllResponseProcessor`) in the
+`ResponseProcessorList`. The four built-in renderers (`JspViewRenderer`,
+`ThymeleafViewRenderer`, `MustacheViewRenderer`, `FreemarkerViewRenderer`)
implement
+`ViewRenderer`. Third-party renderers gain the same ordering guarantee by
implementing the
+interface.
+
+Previously, `SerializedPojoProcessor` (the catch-all) ran before
mixin-registered view
+renderers, causing `@RestOp` methods returning `JspView`, `ThymeleafView`,
`MustacheView`, or
+`FreemarkerView` to emit Juneau-bean HTML instead of invoking the template
engine.
+
+**Before (workaround required):**
+
+```java
+// User had to list JspViewRenderer explicitly ahead of
SerializedPojoProcessor.
+@Rest(responseProcessors={JspViewRenderer.class,
SerializedPojoProcessor.class, ...})
+```
+
+**After (zero config, automatic):**
+
+```java
+@Rest(path="/app", mixins=BasicJspResource.class)
+public class AppResource extends RestServlet {
+ @RestGet("/hello/{name}")
+ public View hello(@Path String name) {
+ return JspView.of("hello.jsp").attr("name", name);
+ }
+}
+// GET /app/hello/Bob → rendered hello.jsp (not a bean-HTML dump of JspView)
+```
+
+This is the foundational fix that unblocks the typed-handler View-return path
for all four
+view modules (TODO-97 / TODO-107 / TODO-108 / TODO-109).
+
#### Framework-internal `@Value` adoption (TODO-92)
Framework-internal config readers in `juneau-rest-server` now route through
the `@Value`
diff --git a/pages/topics/10.14d.JspViewSupport.md
b/pages/topics/10.14d.JspViewSupport.md
index c48f39c0fb..c8a9b47af4 100644
--- a/pages/topics/10.14d.JspViewSupport.md
+++ b/pages/topics/10.14d.JspViewSupport.md
@@ -177,19 +177,17 @@ The Spring `BeanStore` adapter resolves the bean through
End-to-end integration tests for the bridge module under embedded Tomcat
surface two
known constraints that aren't bridge-module bugs but worth documenting up
front:
-1. **Response-processor ordering.** Juneau's default response-processor chain
runs
- `SerializedPojoProcessor` ahead of mixin-registered processors. When the
host class
- has a method returning `JspView`, the host class needs to add
`JspViewRenderer` to its
- *own* `responseProcessors` list to take precedence over the generic POJO
serializer.
- Tracked as a framework enhancement to add a `prepend` mechanism for mixin
processors.
-2. **Servlet-mapping conflicts.** Juneau's `RestServlet` is mapped at `/*`,
which can
+1. **Servlet-mapping conflicts.** Juneau's `RestServlet` is mapped at `/*`,
which can
intercept `RequestDispatcher.forward(...)` calls intended for the
container's JSP
- servlet. The Spring Boot integration tests for this scenario are deferred
until a
- first-class story is in place.
-
-If your deployment hits either of these, file an issue rather than working
around it
-locally — see the follow-up tickets `TODO-96` (response-processor `prepend`)
and
-`TODO-97` (real-container integration tests) for status.
+ servlet. The Spring Boot integration tests for this scenario are tracked as
`TODO-97`
+ (real-container integration tests).
+
+**Response-processor ordering** (previously a known limitation, resolved in
9.5.0 by
+`TODO-96`): `JspViewRenderer` now implements
+[`ViewRenderer`](/site/apidocs/org/apache/juneau/rest/view/ViewRenderer.html)
and is
+automatically positioned before `SerializedPojoProcessor` by the
`ResponseProcessorList`
+partition pass. A `@RestOp` method returning `JspView` reaches the renderer
without any
+extra configuration — the mixin registers the renderer and the framework
ensures ordering.
## Multiple base paths
diff --git a/pages/topics/10.14e.ThymeleafViewSupport.md
b/pages/topics/10.14e.ThymeleafViewSupport.md
index d8faaaf3f0..3e7e01d678 100644
--- a/pages/topics/10.14e.ThymeleafViewSupport.md
+++ b/pages/topics/10.14e.ThymeleafViewSupport.md
@@ -189,15 +189,15 @@ The Spring `BeanStore` adapter resolves the bean through
`ApplicationContext.getBean(BasicThymeleafResource.class)`; no additional
plumbing is
required.
-### Known constraint — response-processor ordering
-
-Juneau's default response-processor chain runs `SerializedPojoProcessor` ahead
of
-mixin-registered processors. When the host class has a method returning
`ThymeleafView`, the
-host class needs to add `ThymeleafViewRenderer` to its *own*
`responseProcessors` list to
-take precedence over the generic POJO serializer. Tracked as a framework
enhancement to add
-a `prepend` mechanism for mixin processors (TODO-96); the real-container
integration tests
-that exercise the `View`-return path under embedded Tomcat / Jetty are
deferred until that
-lands (the Thymeleaf analog of TODO-97 for JSP).
+### Renderer ordering (resolved in 9.5.0)
+
+`ThymeleafViewRenderer` implements
+[`ViewRenderer`](/site/apidocs/org/apache/juneau/rest/view/ViewRenderer.html)
and is
+automatically positioned before `SerializedPojoProcessor` by the
`ResponseProcessorList`
+partition pass (TODO-96). A `@RestOp` method returning `ThymeleafView`
reaches the renderer
+without any extra configuration — the mixin registers the renderer and the
framework ensures
+ordering. Real-container integration tests under embedded Tomcat / Jetty are
tracked as
+`TODO-107`.
## Multiple base paths
diff --git a/pages/topics/10.14f.MustacheViewSupport.md
b/pages/topics/10.14f.MustacheViewSupport.md
index 65330eabe5..c3ee0b04dc 100644
--- a/pages/topics/10.14f.MustacheViewSupport.md
+++ b/pages/topics/10.14f.MustacheViewSupport.md
@@ -194,15 +194,15 @@ public class AppConfig {
The Spring `BeanStore` adapter resolves both beans through
`ApplicationContext.getBean(...)`;
no additional plumbing is required.
-### Known constraint — response-processor ordering
-
-Juneau's default response-processor chain runs `SerializedPojoProcessor` ahead
of
-mixin-registered processors. When the host class has a method returning
`MustacheView`, the
-host class needs to add `MustacheViewRenderer` to its *own*
`responseProcessors` list to
-take precedence over the generic POJO serializer. Tracked as a framework
enhancement to add
-a `prepend` mechanism for mixin processors (TODO-96); the real-container
integration tests
-that exercise the `View`-return path under embedded Tomcat / Jetty are
deferred until that
-lands (the Mustache analog of TODO-97 for JSP and TODO-107 for Thymeleaf).
+### Renderer ordering (resolved in 9.5.0)
+
+`MustacheViewRenderer` implements
+[`ViewRenderer`](/site/apidocs/org/apache/juneau/rest/view/ViewRenderer.html)
and is
+automatically positioned before `SerializedPojoProcessor` by the
`ResponseProcessorList`
+partition pass (TODO-96). A `@RestOp` method returning `MustacheView` reaches
the renderer
+without any extra configuration — the mixin registers the renderer and the
framework ensures
+ordering. Real-container integration tests under embedded Tomcat / Jetty are
tracked as
+`TODO-108`.
## Multiple base paths
diff --git a/pages/topics/10.14g.FreemarkerViewSupport.md
b/pages/topics/10.14g.FreemarkerViewSupport.md
index bc90eca922..cb7f99bb91 100644
--- a/pages/topics/10.14g.FreemarkerViewSupport.md
+++ b/pages/topics/10.14g.FreemarkerViewSupport.md
@@ -229,16 +229,15 @@ The Spring `BeanStore` adapter resolves the
autoconfigured `Configuration` throu
`ApplicationContext.getBean(...)`; no additional plumbing is required. The
bridge default
is bypassed entirely when the starter is on the classpath.
-### Known constraint — response-processor ordering
-
-Juneau's default response-processor chain runs `SerializedPojoProcessor` ahead
of
-mixin-registered processors. When the host class has a method returning
`FreemarkerView`,
-the host class needs to add `FreemarkerViewRenderer` to its *own*
`responseProcessors` list
-to take precedence over the generic POJO serializer. Tracked as a framework
enhancement to
-add a `prepend` mechanism for mixin processors (TODO-96); the real-container
integration
-tests that exercise the `View`-return path under embedded Tomcat / Jetty are
deferred until
-that lands (the FreeMarker analog of TODO-97 for JSP, TODO-107 for Thymeleaf,
and TODO-108
-for Mustache).
+### Renderer ordering (resolved in 9.5.0)
+
+`FreemarkerViewRenderer` implements
+[`ViewRenderer`](/site/apidocs/org/apache/juneau/rest/view/ViewRenderer.html)
and is
+automatically positioned before `SerializedPojoProcessor` by the
`ResponseProcessorList`
+partition pass (TODO-96). A `@RestOp` method returning `FreemarkerView`
reaches the renderer
+without any extra configuration — the mixin registers the renderer and the
framework ensures
+ordering. Real-container integration tests under embedded Tomcat / Jetty are
tracked as
+`TODO-109`.
## Multiple base paths
diff --git a/pages/topics/10.25.ResponseProcessors.md
b/pages/topics/10.25.ResponseProcessors.md
index d55eb09dfa..988a3259ab 100644
--- a/pages/topics/10.25.ResponseProcessors.md
+++ b/pages/topics/10.25.ResponseProcessors.md
@@ -62,3 +62,32 @@ public class MyResource {
}
}
```
+
+## Renderer ordering
+
+View renderers — processors implementing
+[`ViewRenderer`](/site/apidocs/org/apache/juneau/rest/view/ViewRenderer.html)
— are
+automatically repositioned to run before the catch-all serializer
+([`SerializedPojoProcessor`](/site/apidocs/org/apache/juneau/rest/processor/SerializedPojoProcessor.html),
+which implements
[`CatchAllResponseProcessor`](/site/apidocs/org/apache/juneau/rest/processor/CatchAllResponseProcessor.html))
+during `ResponseProcessorList` construction. This means a `@RestOp` method
returning a typed
+`View` subtype (`JspView`, `ThymeleafView`, `MustacheView`, `FreemarkerView`)
reaches the
+corresponding renderer without any explicit ordering annotation or chain
enumeration.
+
+Third-party view renderers gain the same guarantee by implementing
`ViewRenderer`.
+
+```java
+@Rest(path="/app", mixins=BasicJspResource.class)
+public class AppResource extends RestServlet {
+
+ @RestGet("/hello/{name}")
+ public View hello(@Path String name) {
+ return JspView.of("hello.jsp").attr("name", name);
+ }
+}
+// GET /app/hello/Bob → rendered hello.jsp (not a bean-HTML dump of JspView)
+```
+
+The auto-prepend invariant applies even when the user provides an explicit
+`@Rest(responseProcessors=...)` list — any `ViewRenderer` in a custom list is
still ordered
+before any `CatchAllResponseProcessor` in that list.
