Re: Releases (first weeks of December)?
Hi Freeman, Thanks a lot! Next week there are number of Spring related releases, so we could plan to cut the release builds at the end of the next week. Thanks! Best Regards, Andriy Redko > +1 to release in a few weeks. > +1 to retire 3.5.x in the new future. > Please let me know if you want me to cut the release build. > Best Regards > Freeman > On Fri, Nov 15, 2024 at 8:15 AM Andriy Redko wrote: >> Agree, thanks Colm for bringing this one up. I think once we get >> 4.1.0 out of the door, we could announce EOL for 3.5.x within the >> timeline you've suggested. Thanks! >> Best Regards, >> Andriy Redko >> Friday, November 15, 2024, 5:51:38 AM, you wrote: COh>>> +1, but I don't think we have ever maintained 4 different branches COh>>> before. Maybe time to retire 3.5.x in the 1st half of 2025? COh>>> Colm. COh>>> On Fri, Nov 15, 2024 at 6:18 AM Francesco Chicchiriccò COh>>> wrote: On 14/11/24 22:40, Andriy Redko wrote: > Hey folks! > It's been a while since the last releases were cut. I would like to >> propose > to have 3.5.x / 3.6.x / 4.0.x maintenance releases in the first few >> weeks of > December. Also, I believe we should be in a good shape to cut 4.1.0 >> around > this time as well. Any objection or suggestion folks? Thanks! > Best Regards, > Andriy Redko Huge +1, thanks Andriy! Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
Sorry for the delay, just went over through the message thread. So option 1-2
should
indeed work just fine. And for 1st option, you could indeed set the headers
manually.
And in this case, you will need to craft the OpenAPI spec manually, it won't be
properly
deducted.
I don't think adding more attributes to @Multipart would help since it is going
to
in conflict with File / Attachment that by itself source these attributes. But
gimme
some time to experiment over the weekend, I think, intuitively, that this could
work
(doesn't right now):
Response testMessage1(
@HeaderParam("x-correlation-id") @NotNull @Size(min =
10, max = 36)
@Parameter(description="ID of the transaction. Use this ID for log tracing
and incident handling.") String xCorrelationId,
@HeaderParam("Idempotency-Key") @NotNull @Size(min =
10, max = 36)
@Parameter(description="When retrying a failed call, the retry call should
have the same Idempotency Key.") String idempotencyKey,
@FormDataParam(value="messageToSend")
@Parameter(required=true,schema =
@Schema(implementation=MessageToSend.class)) @Multipart(value =
"messageToSend", type="application/json", required= true) MessageToSend
messageToSend,
@FormDataParam(value="upfile1") @Parameter(schema =
@Schema(type =
"string", format = "binary")) Attachment upfile1Detail,
@FormDataParam(value="upfile2") @Parameter(schema =
@Schema(type =
"string", format = "binary")) Attachment upfile2Detail,
@FormDataParam(value="upfile3") @Parameter(schema =
@Schema(type =
"string", format = "binary")) Attachment upfile3Detail)
If we could fold it into :
Response testMessage1(
@HeaderParam("x-correlation-id") @NotNull @Size(min =
10, max = 36)
@Parameter(description="ID of the transaction. Use this ID for log tracing
and incident handling.") String xCorrelationId,
@HeaderParam("Idempotency-Key") @NotNull @Size(min =
10, max = 36)
@Parameter(description="When retrying a failed call, the retry call should
have the same Idempotency Key.") String idempotencyKey,
@FormDataParam(value="messageToSend")
@Parameter(required=true,schema =
@Schema(implementation=MessageToSend.class)) @Multipart(value =
"messageToSend", type="application/json", required= true) MessageToSend
messageToSend,
List attachments)
This is just rough idea, but I will try look more closely into it.
Thanks.
Best Regards,
Andriy Redko
> What I found out when trying to send multipart/form-data requests with CXF
> v3.5:
> 1. You can have just one request body parameter. This can be a
> MultipartBody, or a List but you'll have to set the headers
> (Content-ID,Content-Type, Content-Disposition) yourself.
> 2. I believe you can also have just one request body parameter
> representing a List or a single File. Here a Content-Disposition
> header will be set based on the filename (didn't check this, but the code
> seems to reveal this).
> 3. You can have just one request parameter annotated with @Multipart. This
> will add the Content-ID and Content-Type headers based on the annotation,
> but not the Content-Disposition.
> 4. You can have multiple request body parameters but then all of them need
> to be annotated with @Multipart. This will add the headers Content-Type
> and Content-ID as 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 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 objects) as a list of input parameters
> seems to be a short-coming. It doesn't align well with the OpenAPI 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 form-data
> Hi Andriy,
> Actually, I think you'll have to set the Content-Disposition yourself in
> the Attachment object, while for File objects it will be retrieved from
> the file name.
> Looking at
> https://swagger.io/docs/specification/v3_0/describing-request-body/multipa
> rt-requests/ how would you translate the request body to an method
> signature that works with CXF (v3.5.x)?
> The example shows the 'Content-Disposition' header to be present for all
> multipart parts irrespective of their data type and that is something I
> don't k
Re: Releases (first weeks of December)?
+1, but I don't think we have ever maintained 4 different branches before. Maybe time to retire 3.5.x in the 1st half of 2025? Colm. On Fri, Nov 15, 2024 at 6:18 AM Francesco Chicchiriccò wrote: > > On 14/11/24 22:40, Andriy Redko wrote: > > Hey folks! > > > > It's been a while since the last releases were cut. I would like to propose > > to have 3.5.x / 3.6.x / 4.0.x maintenance releases in the first few weeks of > > December. Also, I believe we should be in a good shape to cut 4.1.0 around > > this time as well. Any objection or suggestion folks? Thanks! > > > > Best Regards, > > Andriy Redko > > Huge +1, thanks Andriy! > > Regards. > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ >
RE: CXF JAX-RS: working with multipart form-data
What I found out when trying to send multipart/form-data requests with CXF v3.5: 1. You can have just one request body parameter. This can be a MultipartBody, or a List but you'll have to set the headers (Content-ID,Content-Type, Content-Disposition) yourself. 2. I believe you can also have just one request body parameter representing a List or a single File. Here a Content-Disposition header will be set based on the filename (didn't check this, but the code seems to reveal this). 3. You can have just one request parameter annotated with @Multipart. This will add the Content-ID and Content-Type headers based on the annotation, but not the Content-Disposition. 4. You can have multiple request body parameters but then all of them need to be annotated with @Multipart. This will add the headers Content-Type and Content-ID as 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 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 objects) as a list of input parameters seems to be a short-coming. It doesn't align well with the OpenAPI 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 form-data Hi Andriy, Actually, I think you'll have to set the Content-Disposition yourself in the Attachment object, while for File objects it will be retrieved from the file name. Looking at https://swagger.io/docs/specification/v3_0/describing-request-body/multipa rt-requests/ how would you translate the request body to an method signature that works with CXF (v3.5.x)? The example shows the 'Content-Disposition' header to be present for all multipart parts irrespective of their data type and that is something I don't know how to achieve in a clean way using CXF. The @org.apache.cxf.jaxrs.ext.multipart.Multipart annotation won't do the job and CXF only adds it for File objects and for Attachment objects (if it is present in the Attachment object). Regards, J.P. -Oorspronkelijk bericht- Van: Andriy Redko Verzonden: woensdag 13 november 2024 23:42 Aan: 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 written is a File Object. The problem is that my application is JPU> generating the file content on the fly, so I have it either as a byte[] or JPU> InputStream. I believe the 'Content-Disposition' will be written for File and Attachment. Respectively, it is going to be read for these multipart content parts as well. This is why the @Multipart annotation has no 'Content-Disposition' or alike (I think). > JPU> Even passing a List doesn't work as the MultiPartProvider will JPU> loop through the list and try to create a DataHandler for an Attachment JPU> object which is also not supported (throws an exception). This is surprising, I will take a look shortly why it does not work. What kind of exception are you getting? Thank you. Best Regards, Andriy Redko JPU> Hi Andriy, 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 written is a File Object. The problem is that my application is JPU> generating the file content on the fly, so I have it either as a byte[] or JPU> InputStream. JPU> This surprises me as according to JPU> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposit ion: JPU> "a multipart/form-data body requires a Content-Disposition header to provide JPU> information about each subpart of the form (e.g., for every form field and JPU> any files that are part of field data)". JPU> Also the Multipart annotation class only allows to specify Content-Type, JPU> Content-ID so there is no way for me to provide 'Content-Disposition' JPU> information on objects like byte[] or InputStream. JPU> Even passing a List doesn't work as the MultiPartProvider will JPU> loop through the list and try to create a DataHandler for an Attachment JPU> object which is also not supported (throws an exception). JPU> The only way I see to pass it is to construct Attachment objects for each JPU> multipart part, with 'Content-Disposition' set, and add them all to a JPU> MultipartBody object and pass this as input parameter to my me
Re: Releases (first weeks of December)?
+1 to release in a few weeks. +1 to retire 3.5.x in the new future. Please let me know if you want me to cut the release build. Best Regards Freeman On Fri, Nov 15, 2024 at 8:15 AM Andriy Redko wrote: > Agree, thanks Colm for bringing this one up. I think once we get > 4.1.0 out of the door, we could announce EOL for 3.5.x within the > timeline you've suggested. Thanks! > > Best Regards, > Andriy Redko > > Friday, November 15, 2024, 5:51:38 AM, you wrote: > > COh> +1, but I don't think we have ever maintained 4 different branches > COh> before. Maybe time to retire 3.5.x in the 1st half of 2025? > > COh> Colm. > > COh> On Fri, Nov 15, 2024 at 6:18 AM Francesco Chicchiriccò > COh> wrote: > >> > >> On 14/11/24 22:40, Andriy Redko wrote: > >> > Hey folks! > >> > > >> > It's been a while since the last releases were cut. I would like to > propose > >> > to have 3.5.x / 3.6.x / 4.0.x maintenance releases in the first few > weeks of > >> > December. Also, I believe we should be in a good shape to cut 4.1.0 > around > >> > this time as well. Any objection or suggestion folks? Thanks! > >> > > >> > Best Regards, > >> > Andriy Redko > >> > >> Huge +1, thanks Andriy! > >> > >> Regards. > >> > >> -- > >> Francesco Chicchiriccò > >> > >> Tirasa - Open Source Excellence > >> http://www.tirasa.net/ > >> > >> Member at The Apache Software Foundation > >> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > >> http://home.apache.org/~ilgrosso/ > >> > >
Re: Releases (first weeks of December)?
Agree, thanks Colm for bringing this one up. I think once we get 4.1.0 out of the door, we could announce EOL for 3.5.x within the timeline you've suggested. Thanks! Best Regards, Andriy Redko Friday, November 15, 2024, 5:51:38 AM, you wrote: COh> +1, but I don't think we have ever maintained 4 different branches COh> before. Maybe time to retire 3.5.x in the 1st half of 2025? COh> Colm. COh> On Fri, Nov 15, 2024 at 6:18 AM Francesco Chicchiriccò COh> wrote: >> >> On 14/11/24 22:40, Andriy Redko wrote: >> > Hey folks! >> > >> > It's been a while since the last releases were cut. I would like to propose >> > to have 3.5.x / 3.6.x / 4.0.x maintenance releases in the first few weeks >> > of >> > December. Also, I believe we should be in a good shape to cut 4.1.0 around >> > this time as well. Any objection or suggestion folks? Thanks! >> > >> > Best Regards, >> > Andriy Redko >> >> Huge +1, thanks Andriy! >> >> Regards. >> >> -- >> Francesco Chicchiriccò >> >> Tirasa - Open Source Excellence >> http://www.tirasa.net/ >> >> Member at The Apache Software Foundation >> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail >> http://home.apache.org/~ilgrosso/ >>
Re: [PR] Bump cxf.micrometer.version from 1.13.7 to 1.14.0 [cxf]
reta merged PR #2149: URL: https://github.com/apache/cxf/pull/2149 -- 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: dev-unsubscr...@cxf.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
