Lukasz Lenart created WW-5742:
---------------------------------
Summary: Visitor validators under a wildcard action are still
cached per resolved action name
Key: WW-5742
URL: https://issues.apache.org/jira/browse/WW-5742
Project: Struts 2
Issue Type: Improvement
Components: XML Validators
Reporter: Lukasz Lenart
Two limitations deliberately carved out of WW-3530 (7.3.0) and left unfiled
until now.
WW-3530 made {{AnnotationActionValidatorManager.buildValidatorKey}} substitute
the action config name for the context only when the class being validated is
the action's own class; a visited object keeps its explicit {{context}} in the
key. That assumes the visitor's context is stable. Two cases where it is not:
*1. Default-context visitor under a wildcard action.*
{{VisitorFieldValidator.validate}} resolves {{visitorContext = (context ==
null) ? ActionContext.getContext().getActionName() : context}}. Without an
explicit {{context}} param the visited class is therefore keyed on the
_resolved_ action name — {{edit_user}}, {{save_user}}, ... for an action config
{{*_user}} — so the validator cache grows one entry per distinct name that
matches the wildcard. This is the bounded-growth shape of WW-2996, just moved
from the action class to the visited class.
*2. The {{<s:form>}} client-side validation render path.*
{{Form.getValidators}} asks {{actionValidatorManager.getValidators(actionClass,
actionName, methodName)}} at render time, where {{actionClass}} is the form
target resolved by name. {{buildValidatorKey}} then compares that class against
the _rendering_ invocation's action and uses the rendering proxy's config to
decide whether the name is a wildcard, so a form targeting a wildcard action
from another page takes the {{context}} branch with the volatile name. (This
path is deprecated since WW-5694 and goes away with WW-5696 in 8.0.0, so it may
be acceptable to leave.)
*Why they were not fixed in WW-3530*: a clean fix needs an explicit visitor
signal through the manager API (the rejected "Approach C") rather than
inferring it from the class comparison. A self-visiting wildcard action still
colliding was accepted as a permanent limitation and is not part of this ticket.
Fix version intentionally left unset: case 1 is fixable within 7.x if the API
addition is additive; if it needs the manager interface to change, it belongs
with 8.0.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
