[
https://issues.apache.org/jira/browse/TOMEE-4657?focusedWorklogId=1031432&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031432
]
ASF GitHub Bot logged work on TOMEE-4657:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Jul/26 08:27
Start Date: 21/Jul/26 08:27
Worklog Time Spent: 10m
Work Description: jungm opened a new pull request, #2845:
URL: https://github.com/apache/tomee/pull/2845
## Problem
On a stock TomEE 11 Plume server, every Bean Validation path that reads
`validation.xml` or a constraint-mapping XML descriptor fails.
Plume depends on `org.eclipse.persistence:eclipselink`, a monolithic
artifact that bundles MOXy alongside the JPA runtime and registers a
`jakarta.xml.bind.JAXBContextFactory` service. MOXy therefore wins the
`ServiceLoader` lookup over the JAXB RI that Plume also ships. MOXy cannot
unmarshal through the SAX `UnmarshallerHandler` chain Apache BVal uses
(`SchemaManager#unmarshal`), so descriptor parsing fails with `DOMException:
NAMESPACE_ERR`.
Two details worth noting, since the Jira description gets them slightly
wrong:
- `JAXBContext.newInstance` itself **succeeds** under MOXy. The failure
happens later, when the unmarshaller receives SAX events.
- BVal's namespace rewriting is **not** the trigger. A native 3.0
`validation.xml`, which needs no rewriting, fails identically.
## Fix
Plume needs a JPA provider, not a JAXB one, so depend on the modular
`org.eclipse.persistence.jpa` artifact instead.
It brings the JPA runtime plus `persistence.core` and `jpa.jpql`, keeps the
`jakarta.persistence.spi.PersistenceProvider` service, and leaves MOXy, SDO,
JPA-RS and the Oracle platforms out of the distribution. `jaxb-runtime` becomes
the only `JAXBContextFactory` provider in Plume, so no system property pin is
required.
Shipped Plume `lib/` after the change:
```
org.eclipse.persistence.jpa-5.0.1.jar
org.eclipse.persistence.core-5.0.1.jar
org.eclipse.persistence.jpa.jpql-5.0.1.jar
jaxb-runtime-4.0.4.jar -> org.glassfish.jaxb.runtime.v2.JAXBContextFactory
(sole provider)
```
## Verification
Both run against a clean build of the Plume distribution:
| TCK | Result |
|---|---|
| Jakarta Persistence 3.2.1 | 2134 tests, 0 failures, 0 errors, plus the
signature test — unchanged from the previous baseline |
| Jakarta Validation 3.1.1 | 1049 tests, 0 failures, signature test 0
failures — **with no `jakarta.xml.bind.JAXBContextFactory` pin configured** |
The validation run is the one that closes the issue: the TCK harness
previously needed a `jakarta.xml.bind.JAXBContextFactory` system property to
pass, and that workaround is no longer necessary.
The persistence run covers the regression risk of dropping the uber-jar. All
17 EclipseLink classes TomEE imports are present in the modular set, and
nothing reaches the removed JPA-RS/SDO/Oracle classes reflectively.
## Notes for reviewers
- **Requires a clean build to observe.** The plume work dir keeps previously
staged jars, so an incremental build can still package the old uber-jar and
make it look like the change had no effect.
- `boms/tomee-plume/pom.xml` is regenerated by `GenerateBoms` during the
build; the only other change there is `asm-analysis` and `asm-util` dropping
out, since they came in via the uber-jar.
- This removes MOXy from Plume entirely. Anyone deliberately relying on MOXy
as their JAXB provider on Plume would be affected, so it may deserve a release
note.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1031432)
Remaining Estimate: 0h
Time Spent: 10m
> Bean Validation XML config fails on stock Plume: MOXy beats JAXB RI in
> ServiceLoader
> ------------------------------------------------------------------------------------
>
> Key: TOMEE-4657
> URL: https://issues.apache.org/jira/browse/TOMEE-4657
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Reporter: Markus Jung
> Assignee: Markus Jung
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On an out-of-the-box TomEE 11 Plume server, every Bean Validation path that
> reads {{validation.xml}} or constraint-mapping XML descriptors fails. Plume
> ships two JAXB providers side by side: EclipseLink MOXy
> ({{eclipselink-5.0.1.jar}}) and the JAXB RI ({{jaxb-runtime-4.0.4.jar}}).
> EclipseLink registers a {{jakarta.xml.bind.JAXBContextFactory}} service, and
> ServiceLoader picks it over the JAXB RI.
> The problem is a mismatch, not a missing feature. Apache BVal rewrites
> namespaces while it parses {{validation.xml}} and constraint-mapping
> descriptors. MOXy rejects that rewriting, so JAXBContext creation fails and
> the whole XML-configuration path breaks. The JAXB RI does not have this
> problem; it parses the rewritten descriptors fine.
> The fix belongs in TomEE, not in applications. Right now the tomee-tck
> harness works around it by pinning the JAXB RI through a
> {{jakarta.xml.bind.JAXBContextFactory}} system property in the server JVM
> ({{runner-standalone/validation/src/tomee-conf/system.properties}}), since
> {{JAXBContext}} reads this property before it asks ServiceLoader. Stock
> Plume, shipped as is, has no such pin, so any application that relies on Bean
> Validation XML config hits this failure the moment it runs on an unmodified
> server. TomEE should set this pin itself, either in the Plume distribution's
> default {{system.properties}} or in the BVal integration code, so
> applications work without a manual JVM property.
> h2. Steps to reproduce / TCK reference
> Deploy the Jakarta Validation TCK ({{validation-tck-tests:3.1.1}}) against
> stock TomEE 11 Plume, with no {{jakarta.xml.bind.JAXBContextFactory}} system
> property set. Run the XML-configuration test paths — the tests that load
> {{validation.xml}} and constraint-mapping XML descriptors. Each one fails
> during JAXBContext creation because MOXy, not the JAXB RI, answers the
> ServiceLoader lookup.
> No TCK exclusion file lists these tests as excluded. The harness works around
> the failure through a server JVM system property, set in
> {{runner-standalone/validation/src/tomee-conf/system.properties}}, rather
> than through {{runner-standalone/exclusions/validation.txt}}. With the pin in
> place, the full validation TCK run (1,049 tests) passes with zero failures.
> Remove the pin from {{system.properties}} and rerun the suite to reproduce
> the failure directly, and to confirm the fix once TomEE pins the factory
> itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
