Skip to content

WW-3427 Add regression test for conversion errors on aliased properties - #1814

Merged
lukaszlenart merged 2 commits into
mainfrom
WW-3427-alias-conversion-error-regression-test
Jul 26, 2026
Merged

WW-3427 Add regression test for conversion errors on aliased properties#1814
lukaszlenart merged 2 commits into
mainfrom
WW-3427-alias-conversion-error-regression-test

Conversation

@lukaszlenart

Copy link
Copy Markdown
Member

Fixes WW-3427

What

Adds a regression test proving that a conversion error thrown while binding an aliased property (via AliasInterceptor) is reported, exactly as it would be for a non-aliased property.

The original report (against 2.1.8.1) was that when an aliased property's custom TypeConverter throws TypeConversionException, the error is never caught by ConversionErrorInterceptor / ConversionErrorFieldValidator.

Why this is test-only

The defect is already fixed in current code. AliasInterceptor binds the alias on a secure child stack with setReportingConversionErrors(context, true) and then copies the resulting conversion errors back into the original ActionContext:

if (clearableStack) {
    stack.getActionContext().withConversionErrors(newStack.getActionContext().getConversionErrors());
}

XWorkConverter.handleConversionException records the TypeConversionException into that context, so ConversionErrorInterceptor picks it up downstream. This path was simply never covered by a test, and the ticket was never verified/closed.

The test

AliasInterceptorTest#testConversionErrorOnAliasedPropertyIsReported drives an action through params -> alias -> conversionError with an aliased BigDecimal property bound through a converter that always throws, and asserts the failure surfaces both in ActionContext.getConversionErrors() and as a field error on the aliased property.

It genuinely guards the behavior: removing the copy-back in AliasInterceptor makes the test fail with "conversion error for aliased property was swallowed", reproducing the original WW-3427 symptom.

Files

  • AliasInterceptorTest.java — new test method
  • AliasConversionAction.java — action with an aliased BigDecimal aliasDest
  • ThrowingTypeConverter.java — converter that always throws TypeConversionException
  • AliasConversionAction-conversion.properties — registers the converter for aliasDest
  • xwork-alias-conversion.xml — dedicated config (params -> alias -> conversionError)

No production changes.

Testing

mvn test -DskipAssembly -pl core -Dtest=AliasInterceptorTest — 8/8 passing.

🤖 Generated with Claude Code

lukaszlenart and others added 2 commits July 26, 2026 10:18
Reproduce the WW-3427 scenario: an aliased property whose custom
TypeConverter throws TypeConversionException. AliasInterceptor already
reports such errors (setReportingConversionErrors on the secure child
stack, then copies conversion errors back to the original ActionContext),
but nothing exercised the alias + conversion-error path.

The test drives an action through params -> alias -> conversionError and
asserts the failure surfaces both in ActionContext.getConversionErrors()
and as a field error, confirming WW-3427 is fixed. Removing the copy-back
in AliasInterceptor makes it fail with "swallowed", proving it guards the
behavior.

Test-only; no production changes.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
RAT flagged the new test resource as having an unapproved license.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
@sonarqubecloud

Copy link
Copy Markdown

@lukaszlenart
lukaszlenart merged commit 0b2bc2b into main Jul 26, 2026
11 of 12 checks passed
@lukaszlenart
lukaszlenart deleted the WW-3427-alias-conversion-error-regression-test branch July 26, 2026 08:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant