[
https://issues.apache.org/jira/browse/CXF-8356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8356.
-------------------------------
Resolution: Fixed
> JAXRS Multipart-Handling broken for InputStream/Datasource parameters
> ---------------------------------------------------------------------
>
> Key: CXF-8356
> URL: https://issues.apache.org/jira/browse/CXF-8356
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.4.0, 3.3.7
> Reporter: Lars Ködderitzsch
> Assignee: Andriy Redko
> Priority: Major
> Fix For: 3.4.2, 3.3.9
>
> Attachments: CXF-8356.zip
>
>
> Multipart attachements mapped to InputStream/Datasource parameters are
> currently broken, due to their respective DelegatingInputStream being closed
> too early.
> As of cxf-3.3.4 this was still working.
> As far as I can see, the early closing happens here:
> {code:java}
> Daemon System Thread [default-workqueue-1] (Suspended (breakpoint at line 46
> in DelegatingInputStream))
> owns: PhaseInterceptorChain (id=49)
> DelegatingInputStream.close() line: 46
> JAXRSUtils.copyAndGetEntityStream(Message) line: 1897
> JAXRSUtils.processRequestBodyParameter(Class<?>, Type, Annotation[],
> Message, OperationResourceInfo) line: 884
> JAXRSUtils.processParameters(OperationResourceInfo,
> MultivaluedMap<String,String>, Message) line: 832
> JAXRSInInterceptor.processRequest(Message, Exchange) line: 214
> JAXRSInInterceptor.handleMessage(Message) line: 78
> PhaseInterceptorChain.doIntercept(Message) line: 308
> ChainInitiationObserver.onMessage(Message) line: 121
> LocalConduit$LocalConduitOutputStream$1.run() line: 88
> AutomaticWorkQueueImpl$3.run() line: 412
>
> AutomaticWorkQueueImpl$1(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker)
> line: 1128
> ThreadPoolExecutor$Worker.run() line: 628
> AutomaticWorkQueueImpl$AWQThreadFactory$1.run() line: 345
> Thread.run() line: 834
> {code}
> I believe this change
> (https://github.com/apache/cxf/commit/dc71ce1635330136e472e0b6fb5ce4a71ae0d474)
> led to this issue, due to `contentType` and `mt` (Mediatype) variable
> disagreeing, leading to unwanted? copy and closing of the stream.
> A few lines below the `contentType` is used again to derive the MediaType,
> which leads me to believe the first`mt` variable is incorrect.
> A local patch for this line made it working again for me, although I am
> uncertain this is the correct fix:
> {code:java}
> MediaType mt = toMediaType(contentType);
> {code}
> For reference, one of the annotated methods producing this issue for us:
> {code:java}
> @POST
> @Path("/pdf")
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> @Operation(summary = "Rendert das übergebene TemplateModel mit Hilfe des
> übergebenen Templates")
> Response getPDF(
> @Parameter(
> description = "Das Template, das zum Rendern der Daten
> benutzt wird",
> content = @Content(schema = @Schema(implementation =
> TemplatePart.class))) @Multipart(
> value = "template", type =
> "application/octet-stream") InputStream template,
> @Parameter(description = "Charset des Templates")
> @QueryParam("charset") String charset,
> @RequestBody(
> description = "Die Daten, die mit Hilfe des übergebenen
> Templates gerendert werden") @Multipart(
> value = "data", type = "application/json")
> TemplateModel data);
> {code}
> In this case this issue led to `template` being a `DelegatingInputStream`
> wrapping another (closed) `DelegatingInputStream` on the server side.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
