neenapj opened a new pull request, #3375:
URL: https://github.com/apache/cxf/pull/3375

   Fixes [CXF-9235](https://issues.apache.org/jira/browse/CXF-9235)
   
   Made changes to` InvocationBuilderImpl.property()` to write directly into 
contextProps, matching how Client/WebTarget already behave.
   **Tests added (InvocationBuilderImplTest)**
   
   testPropertyWrittenToBothFilterPropsAndFlatContext sets 
`SET_EMPTY_REQUEST_CT_PROPERTY = false via Invocation.Builder.property()` and 
asserts two storage locations on `ClientConfiguration.getRequestContext()`:
   
   (a) filterProps sub-map (`requestContext.get("jaxrs.filter.properties")`): 
consumed by [ClientRequestFilter.getProperty()](url) via 
`MessagePropertyHolder`. This path was always written; the test guards it stays 
working.
   (b) flat top-level map 
(`requestContext.get("set.content.type.for.empty.request")`): consumed by the 
HTTP transport via `Message.getContextualProperty()` in 
`Headers.setProtocolHeadersInConnection()`. This was the CXF-9235 bug — only 
(a) was written, so the transport silently ignored the property. The test fails 
on (b) when the fix is reverted (expected:<false> but was:<null>), and passes 
once the flat write is restored. The test also verifies that passing null 
removes the property from both locations.
   No network call is made — the test inspects the ClientConfiguration map 
directly, since `InvocationBuilderImpl.property() `populates it synchronously 
before any dispatch.


-- 
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]

Reply via email to