Lukasz Lenart created WW-5693:
---------------------------------
Summary: Render the dev-mode problem report without FreeMarker
Key: WW-5693
URL: https://issues.apache.org/jira/browse/WW-5693
Project: Struts 2
Issue Type: Task
Components: Core
Reporter: Lukasz Lenart
Fix For: 8.0.0
Follow-up to WW-5690, which deferred the load of
{{/org/apache/struts2/dispatcher/error.ftl}} to first use but left the
dependency in place. This is the other half: remove FreeMarker from
{{DefaultDispatcherErrorHandler}} entirely.
Part of the lean-core work tracked in WW-5689. Sibling tickets WW-5691 and
WW-5692 cover the other two places where core reaches into {{views.freemarker}}.
h2. Work
# Replace {{error.ftl}} with a plain-Java renderer producing the same problem
report.
# Delete {{error.ftl}}, drop the {{FreemarkerManager}} injection, drop the
{{freemarker.template.Template}} import and the {{getTemplate()}} method added
by WW-5690.
After this, {{DefaultDispatcherErrorHandler}} has no view-technology dependency
at all.
h2. Why this is not trivial
{{error.ftl}} is not a flat template. It walks the exception chain, resolves a
root {{Location}} through {{Dispatcher.Locator}}, and renders a source snippet
with *column-level* highlighting — the {{rootloc.columnNumber}} arithmetic
slicing each line into before/highlighted/after spans. Reproducing that
faithfully in Java is where the risk sits, not in the surrounding HTML.
Write a golden-output test pinning the current rendered HTML *before* touching
the renderer, so drift is caught rather than reviewed by eye.
Also worth settling during implementation: the FreeMarker version escapes
interpolated values according to the configured output format. The Java
renderer must escape deliberately rather than inherit that by accident —
exception messages can carry request data. This is a devMode-only page, so it
is a correctness concern rather than a security one, but it should be a
decision and not an oversight.
h2. Target
8.0.0 rather than 7.x. {{error.ftl}} is an internal template, but anyone who
has overridden it on the classpath loses that override, so the removal belongs
with the major release and its migration guide entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
