[
https://issues.apache.org/jira/browse/WW-5757?focusedWorklogId=1045738&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1045738
]
ASF GitHub Bot logged work on WW-5757:
--------------------------------------
Author: ASF GitHub Bot
Created on: 05/Oct/26 14:18
Start Date: 05/Oct/26 14:18
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1990:
URL: https://github.com/apache/struts/pull/1990
Fixes [WW-5757](https://issues.apache.org/jira/browse/WW-5757)
6.x counterpart of #1989 — same change, with `javax.validation` /
`com.opensymphony.xwork2` imports.
`BeanValidationInterceptor` used `ConstraintViolation#getMessage()`, the
message after the Bean Validation provider has interpolated it, as the Struts
text key. The key a developer declares is the constraint's `message` attribute,
which is `getMessageTemplate()`.
## Changes
The error text is now resolved in a new protected `resolveMessage` hook:
- `getMessageTemplate()` is looked up in the Struts bundles, and `getText`
is called with it only when `hasKey` finds it.
- Otherwise the provider's `getMessage()` is used as-is, as literal text. It
is not passed to any text-provider method.
- A template that only references a provider message key, like
`{javax.validation.constraints.NotNull.message}`, is not looked up at all. Such
a template can never be a Struts key. Looking it up would also send its
`{javax` prefix through the child-property lookup, which logs a warning per
violation in dev mode.
## Behaviour changes
- A message produced by the provider is no longer processed as a Struts
message. It is shown exactly as the provider produced it.
- `struts.beanValidation.convertMessageToUtf` now applies only to text
resolved from a Struts bundle. It exists to correct bundles read as ISO-8859-1.
The provider already returns a decoded string, so re-encoding that string could
only corrupt it.
## Tests
- `testProviderMessageIsReportedLiterally`: a `@LuhnCheck` field with the
provider's default message, which includes the validated value, is reported
verbatim. It fails on the previous code.
- `testFieldAction` now asserts the text resolved from a new
`FieldAction.properties` bundle. Before this, no test covered bundle
resolution: the existing key assertions passed only because `getText` falls
back to the key.
- `BeanValidationInterceptorMessageTest`: a provider-key template makes no
text-provider call.
The plugin documentation page will be updated in a separate struts-site PR.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1045738)
Time Spent: 20m (was: 10m)
> BeanValidationInterceptor resolves the interpolated constraint message as a
> text key instead of the message template
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WW-5757
> URL: https://issues.apache.org/jira/browse/WW-5757
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Bean Validation
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 6.13.0, 7.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{BeanValidationInterceptor}} builds the field and action error text from
> {{ConstraintViolation.getMessage()}}, which is the message *after* the Bean
> Validation provider has interpolated it, and passes that string to the Struts
> text provider ({{getText(...)}}) as the text key.
> The key a developer declares is the constraint's {{message}} attribute, which
> is what {{ConstraintViolation.getMessageTemplate()}} returns. Using the
> interpolated message as the key means:
> * a developer-declared Struts key only resolves when the provider leaves the
> message untouched;
> * provider-interpolated text that matches no key is not shown as the provider
> produced it, but is handed to the text provider as default text and processed
> again, as if it were a Struts message.
> The plugin documentation only promises that the {{message}} value is looked
> up as a Struts key; it does not say that provider-produced text goes through
> the text provider.
> h2. Change
> Resolve the error text from the template, and keep the provider's message
> otherwise:
> * look up {{getMessageTemplate()}} in the Struts bundles, and call
> {{getText}} with it only when {{hasKey}} finds it;
> * otherwise use {{ConstraintViolation.getMessage()}} as-is, as literal text;
> * never pass the interpolated message to any text-provider method
> ({{getText}}, {{hasKey}}, {{findText}}).
> h2. Tests
> * A constraint whose provider-interpolated message contains text that the
> Struts text provider would otherwise process is reported exactly as the
> provider produced it.
> * Existing tests where {{message}} is a Struts key keep resolving through the
> bundle.
> Apply the same change on the 6.x line.
> h2. Documentation
> The Bean Validation plugin page should state that {{message}} is looked up as
> a Struts key, and that a message produced by the provider is shown literally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
