(struts) 05/06: WW-3530 docs: document render-path caching limitation

[lu...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

lukaszlenart pushed a commit to branch WW-3530-visitor-validator-cache-key
in repository https://gitbox.apache.org/repos/asf/struts.git

commit 389f87eba2d646f4cec4e3f1643947bdc77a58f0
Author: Lukasz Lenart <lu...@apache.org>
AuthorDate: Sat Jul 25 09:28:17 2026 +0200

    WW-3530 docs: document <s:form> render-path caching limitation
    
    Co-Authored-By: Claude Opus 4.8 <no...@anthropic.com>
---
 ...026-07-25-WW-3530-visitor-validator-cache-key-design.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/docs/superpowers/specs/2026-07-25-WW-3530-visitor-validator-cache-key-design.md b/docs/superpowers/specs/2026-07-25-WW-3530-visitor-validator-cache-key-design.md
index 8e3ff3ead..4a2889aa5 100644
--- a/docs/superpowers/specs/2026-07-25-WW-3530-visitor-validator-cache-key-design.md
+++ b/docs/superpowers/specs/2026-07-25-WW-3530-visitor-validator-cache-key-design.md
@@ -107,6 +107,20 @@ because it now fires only when `clazz == action.getClass()`.
   because `clazz == action.getClass()` takes the wildcard branch. Accepted known
   limitation — extremely contrived, and resolving it would require reintroducing
   the volatile-vs-stable-context ambiguity this fix avoids. Documented, not fixed.
+- **`<s:form>` client-side JS-validation render path** (`Form.getValidators`,
+  `Form.java:295`): this path resolves `actionClass` by *name* (via
+  `ServletUrlRenderer`), not from the live action instance. When the form targets
+  a different action than the one executing, or the live action is a Spring/CGLIB
+  proxy, `clazz.equals(action.getClass())` is false for the action's own top-level
+  lookup, so the key falls to `context` (= action name) instead of
+  `configName|method`. Effect is **caching efficiency only** — extra cache entries
+  per resolved action name on this render path; the correct validators still load,
+  because `buildValidatorConfigs` receives `context` directly, independent of the
+  key. The request-validation hot path (`ValidationInterceptor`) is unaffected:
+  there `clazz` is the live action instance's own class, so WW-2996 caching is
+  fully preserved. Accepted for this change; a follow-up ticket should refine the
+  discriminator for the render path (a robust fix needs an explicit visitor signal
+  threaded through the manager API — the rejected "Approach C").
 - **Non-goal:** no change to the `ActionValidatorManager` interface, to
   `VisitorFieldValidator`, or to `DefaultActionValidatorManager`.