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) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
