WW-3530 Fix visitor-validator cache-key collision under wildcard actions

[lukaszlenart]

Fixes WW-3530

Problem

Two visitor field validators declared on the same field with different context
params (e.g. basic and additional) collide in the validator cache under
wildcard / named-pattern actions: both produce the same cache key, so the
first context's validators are returned for both and the second context's
validators are silently dropped.

Originally reported in 2010 (v2.2.1) when the cache key omitted context
entirely. WW-2996 / WW-3753 / WW-4536 later reworked the key so context is
included for normal actions — fixing the report for non-wildcard actions. The
defect still reproduces for wildcard actions, where the key intentionally
substitutes the action config name for context.

Root cause

AnnotationActionValidatorManager.buildValidatorKey substitutes the action's
config name + method for context whenever the current action is a
wildcard/named-pattern action. That substitution is designed for the action's
own class (where context is the volatile URL-derived action name that WW-2996
must not key on). But it was applied too broadly — it also fired when validating
a visited object under a visitor validator, whose context is a stable,
explicit param, and wrongly discarded it.

Fix

Narrow the substitution to the case it was designed for: apply the config-name
key only when the class being validated is the action's own class
(clazz.equals(invocation.getAction().getClass())). For any other class (a
visited object), key on context — matching DefaultActionValidatorManager.

The request-validation hot path (ValidationInterceptor →
getValidators(action.getClass(), …)) always validates the live action
instance's own class, so WW-2996's single-cache-entry-per-wildcard-action
behavior is fully preserved. The cache-key change only affects cache reuse; it
never changes which validators load (buildValidatorConfigs receives context
directly).

Tests

• New unit tests in AnnotationActionValidatorManagerTest:
  • visited class under a wildcard action → distinct keys per context (the
    failing-before / passing-after case)
  • action's own class under a wildcard action → key ignores context (WW-2996
    behavior pinned)
• Regression: full AnnotationActionValidatorManagerTest (14/14) and
  VisitorFieldValidatorTest / VisitorFieldValidatorModelTest /
  DefaultActionValidatorManagerTest (23/23) pass.
• Draft note: the full core module suite has not yet been run in this
  branch — to be completed before marking ready for review.

Known limitations (follow-up ticket to be filed)

Both need an explicit visitor signal threaded through the manager API to fix
cleanly, and are memory-only (correct validators still load):

• Default-context visitor under a wildcard action: a visitor validator with
  no explicit context defaults to the resolved action name, which is volatile
  under a wildcard action — so the visited-class key moves from stable
  (configName|method) to volatile, causing bounded WW-2996-style cache growth.
  Disappears when the visitor declares an explicit context.
• <s:form> client-side JS-validation render path: resolves the action
  class by name rather than from the live action instance, so for a
  cross-action or proxied form the action's own top-level lookup falls to the
  context branch under a wildcard action (extra cache entries, correctness
  unaffected).

Design spec and implementation plan are included under docs/superpowers/.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Fixes a long-standing validator cache-key collision affecting visitor field validators under wildcard/named-pattern actions by narrowing when wildcard config-name substitution is applied. This ensures distinct visitor context values don’t collapse into the same cached validator entry for visited model classes, while preserving the WW-2996 wildcard-action caching behavior for the action’s own class.

Changes:

• Adjust AnnotationActionValidatorManager.buildValidatorKey() to only substitute configName|method for wildcard actions when validating the action’s own class.
• Add unit tests that pin both the WW-3530 visited-class behavior and the WW-2996 action-class behavior under wildcard actions.
• Add design/spec and implementation plan documentation under docs/superpowers/.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
docs/superpowers/specs/2026-07-25-WW-3530-visitor-validator-cache-key-design.md	Design/spec documenting root cause, fix approach, and known limitations.
docs/superpowers/plans/2026-07-25-WW-3530-visitor-validator-cache-key.md	Step-by-step implementation plan and test guidance for WW-3530.
core/src/main/java/org/apache/struts2/validator/AnnotationActionValidatorManager.java	Narrow wildcard cache-key substitution to the action’s own class; adds debug logging (flagged in review).
core/src/test/java/org/apache/struts2/validator/AnnotationActionValidatorManagerTest.java	Adds targeted unit tests for visited-class vs action-class key behavior under wildcard actions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud