ted https://issues.apache.org/jira/browse/CXF-9138.
> Regards,
> J.P.
> -Oorspronkelijk bericht-
> Van: Andriy Redko
> Verzonden: dinsdag 20 mei 2025 2:28
> Aan: Jean Pierre URKENS ;
> dev@cxf.apache.org
> Onderwerp: Re: CXF JAX-RS: working with multipart form-data
> H
Onderwerp: Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
I believe the rfc-7578 [1] deprecates Content-Transfer-Encoding (section
4.7), so
it should be safe to remove it. Please feel free to file an issue [2], it
should be an
easy fix. Thank you!
[1] https://www.rfc-editor.org/rfc/rfc7578
essages")
> .accept(MediaType.APPLICATION_JSON_TYPE);
>
> return
> wc.post(Entity.entity(body,MediaType.MULTIPART_FORM_DATA_TYPE));
> }
> -Oorspronkelijk bericht-
> Van: Andriy Redko
> Ver
messages")
.accept(MediaType.APPLICATION_JSON_TYPE);
return
wc.post(Entity.entity(body,MediaType.MULTIPART_FORM_DATA_TYPE));
}
-----Oorspronkelijk bericht-
Van: Andriy Redko
Verzonden: maandag 19 mei 2025 17:06
Aan: Jean Pierre URKENS ;
dev@c
kelijk bericht-
> Van: Andriy Redko
> Verzonden: zaterdag 17 mei 2025 3:45
> Aan: Jean Pierre URKENS ;
> dev@cxf.apache.org
> Onderwerp: Re: CXF JAX-RS: working with multipart form-data
> Hi Jean,
> Ah interesting, I briefly checked [1], [2] and indeed Content-ID is
>
@cxf.apache.org
Onderwerp: Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
Ah interesting, I briefly checked [1], [2] and indeed Content-ID is
not mentioned there. I will try to look over the weekend what is
happening,
thank you.
[1] https://www.rfc-editor.org/rfc/rfc2388.html
[2] https://www.rfc
mei 2025 3:41
> Aan: Jean Pierre URKENS ;
> dev@cxf.apache.org
> Onderwerp: Re: CXF JAX-RS: working with multipart form-data
> Hi Jean,
> On the first glance (comparing the example request and the real request
> you are sending), I see no issues: there is one attachment in both of them
&g
"attachments" : [ {
> "httpPartName" : "upfile1",
> "mainContent" : true,
> "attachmentSigned" : false
> }],
> "bodyMainContent" : false,
>
{
> "httpPartName" : "upfile1",
> "mainContent" : true,
> "attachmentSigned" : false
> }],
> "bodyMainContent" : false,
> "businessDataList" :
c2b190
> Content-Type: application/json
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: form-data; name="messageToSend";
> {
> "delivery" : "EBOX",
> "eboxDeliveryData" : {
> "recipient" : {
gt; to keep bean validation active any suggestions on how to
> resolve/circumvent this issue, e.g.:
> - using another bean validation library
> - disabling validation for a specific method (is this possible?)
> -
> Regards,
> J.P. Urkens
> -Oorspronkelijk bericht-
> Van: Jean
" : null,
"httpPartName" : "upfile2",
"mainContent" : false,
"digest" : null,
"attachmentSigned" : false
}, {
"attachmentTitle" : null,
"httpPartName" : "upfile3",
"mainCont
Regards,
J.P. Urkens
-Oorspronkelijk bericht-
Van: Jean Pierre URKENS
Verzonden: maandag 18 november 2024 10:20
Aan: 'Andriy Redko' ; 'dev@cxf.apache.org'
Onderwerp: RE: CXF JAX-RS: working with multipart form-data
Validation is done using apache library bval-jsr-2.0.5.
"attachmentTitle" : null,
"httpPartName" : "upfile2",
"mainContent" : false,
"digest" : null,
"attachmentSigned" : false
}, {
"attachmentTitle" : null,
"httpPartName" : &qu
c according to RFC822'
> enclosed within '<>' and it is used to reference a multipartbody part in
> another part of the message. This doesn't seem to be the context in which
> it is used in
> JAX-RS messages, further the url-addr-spec actually tells me there should
> a
specified in the annotation, but it will not add a
>> 'Content-Disposition' header.
>> So the OpenAPI specification/examples as enlisted below requires us to
>> convert everything to attachments (to get the Content-Disposition header
>> in place) and either send a request b
nd a request body consisting of a
List
> or MultipartBody.
> The fact that in CXF-v3.5.x you can not:
> * specify a Content-Disposition header for a @Multipart input parameter
> * mix Attachment objects with @Multipart annotated objects (which by
the
> stack are converted to Attachment
* specify a Content-Disposition header for a @Multipart input parameter
> * mix Attachment objects with @Multipart annotated objects (which by the
> stack are converted to Attachment objects) as a list of input parameters
> seems to be a short-coming. It doesn't align well with the
nAPI v3.0.x
specification.
Is this a correct conclusion?
Regards,
J.P. Urkens
-Oorspronkelijk bericht-
Van: Jean Pierre URKENS
Verzonden: donderdag 14 november 2024 11:29
Aan: 'Andriy Redko' ; 'dev@cxf.apache.org'
Onderwerp: RE: CXF JAX-RS: working with multipart fo
idempotencyKey,
MultipartBody body)
throws GeneralSecurityException, AuthorizationException;
RESULT:
This is the only case where I can send/receive a REQ/RESP where all
multipart parts have a Content-Disposition header set. However I am not sure
whether its fully co
Jean Pierre URKENS ;
dev@cxf.apache.org
Onderwerp: Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
JPU> When looking at the classes MultipartProvider and JAXRSUtils (cxf
v3.5.9)
JPU> then it shows that only object for which a 'Content-Disposition' header
will
JPU> be writ
; MultipartBody object and pass this as input parameter to my method
JPU> signature. But then I loose all swager information for input objects that
JPU> are not byte[] or InputStream.
JPU> Am I missing something?
JPU> Regards,
JPU> J.P.
JPU> -Oorspronkelijk bericht-
JPU> Van:
tober 2024 2:52
Aan: Jean Pierre URKENS ;
dev@cxf.apache.org
Onderwerp: Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
Yeah, I think the @Multipart + Attachment may not work, but you could accept
the List instead, right? (since you send many).
The logging configuration does not seem right: you
sage (attachments are rather small as it is a
JPU> test).
JPU> Well I used wireshark to get the full message and it doesn't show any
JPU> Content-Disposition headers for the multipart elements.
JPU> Regards,
JPU> J.P. Urkens
JPU> -Original Message-
JPU> From: Andr
rkens
-----Original Message-
From: Andriy Redko
Sent: donderdag 3 oktober 2024 1:01
To: Jean Pierre URKENS ; dev@cxf.apache.org
Subject: Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
JPU> What is the correct way to annotate a file attachment as part of a
JPU>
setup with just one file attachment. In the real interface up
to
JPU> 20 attachments can be passed. Somehow I need to know which part relates to
JPU> which attachment or not?
JPU> -> Question-04: At the server implemtation side, since
upfile1Detail is
JPU> p
--Original Message-
From: Andriy Redko
Sent: vrijdag 5 juli 2024 2:16
To: Jean Pierre URKENS ; dev@cxf.apache.org
Subject: Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
Here is how you could make it work (there is some magic knowledge involved
sadly). First of all, define such
:
type: string
format: binary
upfile16:
type: string
format: binary
upfile17:
type: string
format: binary
upfile18:
type: str
cation/octet-stream",
> required = false) Attachment upfile18Detail,
>
> @Parameter(schema = @Schema(type = "string", format = "binary"))
> @Multipart(value = "upfile19", type="application/octet-stream",
> required = false) Attachment upfile19
,
> @Parameter(schema
> = @Schema(type = "string", format = "binary")) @Multipart(value = "upfile19",
> type="application/octet-stream", required = false) Attachment upfile19Detail,
&
ma = @Schema(type = "string", format = "binary"))
@Multipart(value = "qrfile", type="application/octet-stream", required =
false) Attachment qrfileDetail);
I’ve attached the generated openapi specification. It only contains the
‘messageToSend’ as part of
Hi Jean Pierre,
I suspect the @Multipart annotation is coming from CXF
(org.apache.cxf.jaxrs.ext.multipart.Multipart), right? If yes,
this is not a part of JAX-RS specification but CXF specific extension. You may
need to add Swagger API annotation to
the parameters in question:
@Parameter(s
32 matches
Mail list logo
