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 <[email protected]>
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 <[email protected]>
---
 ...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`.
 

Reply via email to