[
https://issues.apache.org/jira/browse/CXF-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642388#comment-16642388
]
ASF GitHub Bot commented on CXF-7860:
-------------------------------------
andymc12 commented on issue #453: CXF-7860: Ensure @FormParam parms are
consistent with Form entities
URL: https://github.com/apache/cxf/pull/453#issuecomment-427958475
@reta Thanks so much! That is a much better solution that what I had
originally proposed. I had also considered that the "right approach" would be
to refactor the phase when parameters were processed, but I think this solution
is cleaner - and should not disrupt normal cases.
I've left the test cases unaltered, but I removed my changes from
`JAXRSInvoker` and instead changed `JAXRSUtils` as you suggested. This passes
all of the unit tests and the systests (including my new one). Can you take a
look at the latest changes?
Thanks again!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> JAX-RS @FormParam parameters are not updated when form content is modified
> --------------------------------------------------------------------------
>
> Key: CXF-7860
> URL: https://issues.apache.org/jira/browse/CXF-7860
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.2.6
> Reporter: Andy McCright
> Assignee: Andy McCright
> Priority: Major
>
> The JAX-RS community noticed a difference in behavior between CXF and
> Jersey/RESTEasy where form data in the HTTP body is modified prior to
> invoking the resource method. There are two differences noted:
> 1) CXF does not invoke a MessageBodyReader (or any ReaderInterceptors) when
> there is no entity parameter. I believe that this is proper behavior - or at
> least an appropriate optimization since there is no parameter, why bother
> creating one with a MBR (and it's associated ReaderInterceptors)?
> 2) When the resource method contains both a Form parameter (entity) _and_ a
> parameter annotated with `@FormParam`, and a Filter or interceptor, etc. has
> modified the content of of the HTTP body, the value injected for the
> `@FormParam` parameter does not reflect those modifications, but the Form
> entity parameter does. This seems inconsistent, and (IMO) violates the
> spirit of the spec - note that there is no TCK test for this case, so CXF is
> still compliant - but it differs from other implementations. Here is an
> example:
>
>
> {code:java}
> @Provider
> public class FormReaderInterceptor implements ReaderInterceptor {
> private static final Logger LOG =
> LogUtils.getL7dLogger(FormReaderInterceptor.class);
> @Override
> public Object aroundReadFrom(ReaderInterceptorContext ctx) throws
> IOException, WebApplicationException {
> BufferedReader br = new BufferedReader(new
> InputStreamReader(ctx.getInputStream()));
> String line;
> while ((line = br.readLine()) != null) {
> LOG.info("readLine: " + line);
> }
> ByteArrayInputStream bais = new
> ByteArrayInputStream("value=MODIFIED".getBytes());
> ctx.setInputStream(bais);
> return ctx.proceed();
> }
> }
> {code}
>
> {code:java}
> @POST
> public Response processForm(@FormParam("value") String value, Form form)
> {...
> {code}
>
> If the HTTP request body contains "value=ORIGINAL", then when CXF invokes the
> processForm method, it will pass "ORIGINAL" to the String value, but will
> pass a Form object that contains a MultivaluedMap with entry
> "value=MODIFIED". To be consistent with Jersey and RESTEasy, CXF should
> inject MODIFIED as the String value.
>
> See JAX-RS API [Issue
> 659|https://github.com/eclipse-ee4j/jaxrs-api/issues/659] for more details.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
