Croway opened a new pull request, #24813: URL: https://github.com/apache/camel/pull/24813
## Summary _Claude Code on behalf of Croway_ The `JaxbDataFormat.unmarshal()` and `toElement()` methods write the header-derived `CamelJaxbPartClass` value directly into the shared **instance field** `this.partClass`. Since a `DataFormat` is shared across all exchanges in a route step, this causes: - **Stickiness**: once any exchange carries the header, `partClass` remains non-null permanently — all subsequent exchanges without the header silently unmarshal/marshal using the leaked class. - **Data race**: concurrent exchanges with different headers cross-contaminate. The fix uses a **local variable** (`effectivePartClass`) instead of mutating the instance field, matching the pattern already used by Jackson, CBOR, Gson, and Jsonb data formats. The bug was introduced in 2017 (CAMEL-5723, commit `03519184b36a`) and carried through the 2024 refactoring (commit `f0b4bb237331`). ## Changes - **`JaxbDataFormat.java`**: Replace `this.partClass = ...` with local `effectivePartClass` in both `unmarshal()` and `toElement()`. - **New test `JaxbPartClassHeaderStatePollutionTest.java`**: Two test cases (unmarshal + marshal) that send Exchange 1 with header, then Exchange 2 without, asserting no state leaks. ## Test plan - [x] New test `JaxbPartClassHeaderStatePollutionTest` covers both unmarshal and marshal paths - [x] All 113 existing camel-jaxb tests pass (`mvn verify` in `components/camel-jaxb`) - [x] Verified that existing `JaxbDataFormatPartClassHeaderTest` and `JaxbDataFormatPartClassTest` still pass (header-driven and configured partClass paths) 🤖 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]
