[
https://issues.apache.org/jira/browse/WW-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5742:
------------------------------
Fix Version/s: 8.0.0
> 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
> Priority: Major
> Fix For: 8.0.0
>
>
> 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)
