[jira] [Commented] (WW-5693) Render the dev-mode problem report without FreeMarker

["Lukasz Lenart (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WW-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107314#comment-18107314 ] 

Lukasz Lenart commented on WW-5693:
-----------------------------------

WW-5691 has been retargeted from 7.4.0 to 8.0.0 to pair with this ticket. Both replace an internal-but-overridable FreeMarker template in core with a plain-Java renderer, so they should land together under a single migration-guide entry along the lines of "core renders its own fallback pages without FreeMarker".

They also share one trap worth stating once, in both places: {{FreemarkerManager}} configures {{HTMLOutputFormat.INSTANCE}} with {{ENABLE_IF_DEFAULT_AUTO_ESCAPING_POLICY}}, so every interpolation in {{error.ftl}} and {{wait.ftl}} is HTML-escaped today without anyone having to think about it. A hand-written Java renderer loses that. What is currently safe by configuration becomes safe only by discipline, so escaping has to be an explicit decision in both rewrites rather than something inherited.

> 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
>            Priority: Major
>             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)