Re: Release 4.0.5 / 3.6.4 / 3.5.9?
Hi Gary, I sadly could only refer to the issue [1] regarding vague timelines (in comments). Thank you. [1] https://issues.apache.org/jira/browse/CXF-8671 Best Regards, Andriy Redko > Hi Andriy, > Do you have a (however vague) estimate for 4.1.0? > TY! > Gary > On Thu, Jul 11, 2024, 4:41 PM Andrey Redko wrote: >> Hi Gary, >> We do not release milestones or beta / alpha / ... bits, please use snaphots >> as you do now (meanwhile the team is working towards 4.1.0 release). Thank >> you. >> Best Regards, >> Andriy Redko >> On Thu, Jul 11, 2024, 4:35 p.m. Gary D. Gregory wrote: >>> Hi All, >>> How about a 4.1.0 milestone/beta/alpha release? >>> I have a project that requires Jetty 12 support and the only way I can get >>> it working is with a 4.1.0-SNAPSHOT. >>> Thank you for considering it :) >>> Gary >>> On 2024/07/04 20:58:36 Andriy Redko wrote: >>>> Hey folks, >>>> >>>> It's been 3 months since the last release train, any objections to cut >>>> new releases? On my side, there are few issues in progress that could >>>> be moved to the next release(s), a number of important fixes are long >>>> overdue. >>>> >>>> Thanks! >>>> >>>> Best Regards, >>>> Andriy Redko >>>> >>>>
Re: Release 4.0.5 / 3.6.4 / 3.5.9?
Thanks a lot Freeman! I will rearrange my JIRAs appropriately before that. Thanks again! Best Regards, Andriy Redko Thursday, July 4, 2024, 6:49:12 PM, you wrote: FF> +1 to do the release. FF> I can start to do it sometime next week if there are no other objections. FF> Cheers FF> Freeman FF> On Thu, Jul 4, 2024 at 4:59 PM Andriy Redko wrote: >> Hey folks, >> >> It's been 3 months since the last release train, any objections to cut >> new releases? On my side, there are few issues in progress that could >> be moved to the next release(s), a number of important fixes are long >> overdue. >> >> Thanks! >> >> Best Regards, >> Andriy Redko >> >>
Re: CXF JAX-RS: working with multipart form-data
upfile15Detail,
@FormDataParam("upfile16") @Parameter(schema = @Schema(type =
"string", format = "binary")) @Multipart(value = "upfile16",
type="application/octet-stream", required = false) Attachment upfile16Detail,
@FormDataParam("upfile17") @Parameter(schema = @Schema(type =
"string", format = "binary")) @Multipart(value = "upfile17",
type="application/octet-stream", required = false) Attachment upfile17Detail,
@FormDataParam("upfile18") @Parameter(schema = @Schema(type =
"string", format = "binary")) @Multipart(value = "upfile18",
type="application/octet-stream", required = false) Attachment upfile18Detail,
@FormDataParam("upfile19") @Parameter(schema = @Schema(type =
"string", format = "binary")) @Multipart(value = "upfile19",
type="application/octet-stream", required = false) Attachment upfile19Detail,
@FormDataParam("upfile20") @Parameter(schema = @Schema(type =
"string", format = "binary")) @Multipart(value = "upfile20",
type="application/octet-stream", required = false) Attachment upfile20Detail,
@FormDataParam("qrfile") @Parameter(schema = @Schema(type = "string",
format = "binary")) @Multipart(value = "qrfile",
type="application/octet-stream", required = false) Attachment qrfileDetail
) {
}
With that, you will get a nice request body schema (publishing a bit large YAML
snippet to preserve the context):
paths:
/sample/messages:
post:
tags:
- messages
summary: "Send a message, using a channel (email, paper mail, ebox) and
delivery\
\ method (registered or normal) of your choice. More than 6 upfiles
only supported\
\ for PAPER delivery."
operationId: createMessage
parameters:
- name: x-correlation-id
in: header
description: ID of the transaction. Use this ID for log tracing and
incident
handling.
required: true
schema:
maxLength: 36
minLength: 10
type: string
- name: Idempotency-Key
in: header
description: "When retrying a failed call, the retry call should have
the\
\ same Idempotency Key."
schema:
maxLength: 36
minLength: 10
type: string
requestBody:
content:
multipart/form-data:
schema:
type: object
properties:
upfile1:
type: string
format: binary
upfile2:
type: string
format: binary
upfile3:
type: string
format: binary
upfile4:
type: string
format: binary
upfile5:
type: string
format: binary
upfile6:
type: string
format: binary
upfile7:
type: string
format: binary
upfile8:
type: string
format: binary
upfile9:
type: string
format: binary
upfile10:
type: string
format: binary
upfile11:
type: string
format: binary
upfile12:
type: string
format: binary
upfile13:
type: string
format: binary
upfile14:
type: string
format: binary
upfile15:
type: string
format: binary
upfile16:
type: string
format: binary
upfile17:
type: string
format: binary
upfile18:
type: string
format: binary
upfile19:
type: string
format: binary
upfile20:
type: string
format: binary
qrfile:
type: string
format: binary
The key here is @FormDataParam annotation which (originally) comes from Jersey
but has special treatment in Swagger
Core (but, likely, no attribution to Jersey).
Hope it helps!
Thank you.
Best Regards,
Andriy Redko
> V2.2.22 (15/05/2024) is the latest version of io.swagger.core.v3 libraries.
> I upgrade to this version to make sure I had the late
Release 4.0.5 / 3.6.4 / 3.5.9?
Hey folks, It's been 3 months since the last release train, any objections to cut new releases? On my side, there are few issues in progress that could be moved to the next release(s), a number of important fixes are long overdue. Thanks! Best Regards, Andriy Redko
Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
Interesting, I was experimenting with different ways to express what you need,
but no luck
so far, I will try to spend a bit more time on that this week since OAS 3.x
does support multipart
[1] but we may indeed hit the limitation(s) of this particular Swagger Core
version. Thank you.
[1]
https://swagger.io/docs/specification/describing-request-body/multipart-requests/
Best Regards,
Andriy Redko
> Hi Andriy,
>
> I already tried this but it didn't work. E.g. for following API interface
> specification:
>
> /**
> * Send a message, using a channel (email, paper mail,
> ebox) and delivery method (registered or normal) of your choice. More than 6
> upfiles only supported for PAPER delivery.
> *
> */
> @POST
> @Path("/messages")
> @Consumes("multipart/form-data")
> @Produces({ "application/json" })
> @Operation(
> summary = "Send a
> message, using a channel (email, paper mail, ebox) and delivery method
> (registered or normal) of your choice. More than 6 upfiles only supported for
> PAPER delivery.",
> tags =
> {"messages" },
>
> operationId="createMessage",
>
> security=@SecurityRequirement(name="BearerAuthentication"))
> @ApiResponses({
> @ApiResponse(
>
> responseCode = "201",
>
> description = "Created",
>
> content =
> @Content(mediaType=MediaType.APPLICATION_JSON,array=@ArraySchema(schema=@Schema(implementation=SendStatusMessage.class))),
>
> headers = {@Header(
>
>
>
> name="X-Magda-Exceptions",
>
>
>
> required=false,
>
>
>
> description="Only used in the context of EBOX delivery and if there was a
> problem with the consent of the receiver's ebox.",
>
>
>
> schema=@Schema(implementation=MagdaExceptionList.class))
>
>
> }),
> @ApiResponse(
>
> responseCode = "400",
>
> description = "Invalid data supplied",
>
> content =
> @Content(mediaType=MediaType.APPLICATION_JSON,schema=@Schema(implementation=ErrorMessage.class))),
> @ApiResponse(
>
> responseCode = "401",
>
>
Re: CXF JAX-RS: working with multipart form-data
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(schema = @Schema(type = "string", format = "binary"))
Hope it helps.
Thank you.
Best Regards,
Andriy Redko
Monday, July 1, 2024, 12:09:17 PM, you wrote:
> Hi all,
> I am having problems to correctly annotate service methods which consumes
> multipart/form-data that contains attachments next to other model objects.
> I’ve an openapi specification that contains following requestBody definition:
> /messages:
> post:
> tags:
> - "messages"
> summary: "Send a message, using a channel (email, paper mail, ebox) and
> delivery method (registered or normal) of your choice. More than 6 upfiles
> only supported for PAPER delivery."
> operationId: createMessage
> parameters:
> - $ref: '#/components/parameters/CorrelationId'
> - $ref: '#/components/parameters/Idempotency-Key'
> requestBody:
> content:
> multipart/form-data:
> schema:
> type: object
> required:
> - messageToSend
> properties:
> messageToSend:
> $ref: '#/components/schemas/MessageToSend'
> upfile1:
> type: string
> format: binary
> nullable: true
> upfile2:
> type: string
> format: binary
> nullable: true
> upfile3:
> type: string
> format: binary
> nullable: true
> upfile4:
> type: string
> format: binary
> nullable: true
> upfile5:
> type: string
> format: binary
> nullable: true
> upfile6:
> type: string
> format: binary
> nullable: true
> upfile7:
> type: string
> format: binary
> nullable: true
> upfile8:
> type: string
> format: binary
> nullable: true
> upfile9:
> type: string
> format: binary
> nullable: true
> upfile10:
> type: string
> format: binary
> nullable: true
> upfile11:
> type: string
> format: binary
> nullable: true
> upfile12:
> type: string
> format: binary
> nullable: true
> upfile13:
> type: string
> format: binary
> nullable: true
> upfile14:
> type: string
> format: binary
> nullable: true
> upfile15:
> type: string
> format: binary
> nullable: true
> upfile16:
> type: string
> format: binary
> nullable: true
> upfile17:
> type: string
> format: binary
> nullable: true
> upfile18:
> type: string
> format: binary
> nullable: true
> upfile19:
> type: string
> format: binary
> nullable: true
> upfile20:
> type: string
> format: binary
> nullable: true
> qrfile:
> type: string
> format: binary
> nullable: true
> required: true
> When using the openapi-generator-maven-plugin v7.6.0 it generates following
> method signature:
> @POST
> @Path("/messages")
> @Consumes("multipart/form-data")
> @Produces({ "application/json" })
> @Operation(
> summary = "Send a message, using a channel (ema
Re: CXF 4.1.0 ?
Hi, Besides the ones Jamie already mentioned: - we need to release cxf-xjc-utils (https://issues.apache.org/jira/browse/CXFXJC-48) - https://issues.apache.org/jira/browse/CXF-8671 (some dependency updates which are planned) - https://issues.apache.org/jira/browse/CXF-9029 The significant (I would not be afraid to say insane) amount of work has gone / is going into fixing to JDK-11 HttpClient based conduit - this is not related to 4.1.0 in particular but the meta problem for current and upcoming release branches. Thank you. Best Regards, Andriy Redko JG> The in-progress cards for 4.1.0 include: JG> CXF-9008 FIPS Support JG> CXF-9005 EE10 JAX-RS TCK Test Failures JG> CXF-9007 NPE in XMLStreamDataWriter JG> CXF-8976 Update to OpenTelemetry v1.39.0 JG> CXF-8969 Update to Brave 6 JG> Not sure what the Committers/PMCs have planned for 4.1, my assumption JG> is that FIPS support is the largest new feature inflight. JG> On Mon, Jun 10, 2024 at 5:25 AM Richard Zowalla wrote: >> >> Hi all, >> >> What needs to be done for 4.1.0 to be ready for release? >> >> I am asking, because CXF 4.1.x (EE10) is a blocker for the next TomEE >> milestone and we might be able to help with it :) >> >> Gruß & tx >> Richard
Re: Request for Apache CXF 3.5.9 release timelines
Hi Nikhil, Although dependencies in question were updated, there is no reason to wait for release: you could always provide dependency overrides for the ones affected using the build tool of your choice. Thank you. Best Regards, Andriy Redko Monday, June 3, 2024, 5:52:50 AM, you wrote: sn> HI Team, sn> We have recently figured out a critical security vulnerability for sn> spring-framework that is embedded within CXF package - the same has been sn> addressed via ticket https://issues.apache.org/jira/browse/CXF-9016 which sn> is expected to be available in next release versions sn> 3.5.9 sn> <https://issues.apache.org/jira/issues/?jql=project+%3D+CXF+AND+fixVersion+%3D+3.5.9> sn> , 4.1.0 sn> <https://issues.apache.org/jira/issues/?jql=project+%3D+CXF+AND+fixVersion+%3D+4.1.0> sn> , 4.0.5 sn> <https://issues.apache.org/jira/issues/?jql=project+%3D+CXF+AND+fixVersion+%3D+4.0.5> sn> , 3.6.4 sn> <https://issues.apache.org/jira/issues/?jql=project+%3D+CXF+AND+fixVersion+%3D+3.6.4> sn> Could you please provide any update (if possible) on the timelines for sn> these versions ? Particularly version 3.5.9 ? sn> Thank you in advance. sn> Regards, sn> Nikhil
Re: SpringWebUtils in CXF in TomEE
Thanks a lot Romain for the suggestion and Jonathan for confirming it applies nicely. Best Regards, Andriy Redko >> Something like loading the class SpringWebUtils in cxfrsservice#init JG> method would be sufficient IMHO. JG> That looks like it works really well, thank you! I'll get that checked in. JG> Jon JG> On Mon, May 20, 2024 at 4:57 PM Romain Manni-Bucau JG> wrote: >> Le lun. 20 mai 2024 à 17:29, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> a écrit : >> >> > Thanks Andriy and Romain for your replies. >> > >> > > This is quite an interesting issue, is it possible to share (or point >> out >> > to an example) small reproducer project for this problem? >> > >> > Yes - here's a reproducer: https://github.com/jgallimore/demo >> > >> > If you clone this and run mvn clean install tomee:run, it will boot up a >> > TomEE 9.1.3 (which includes CXF 4.0.4). If you invoke a GET >> > http://localhost:8080/hello you'll see the error on the console. >> > >> > > * openejb.cxf.CxfContainerClassLoader is false >> > >> > This didn't work. >> > >> > > * cxf is in the webapp, tomee cxf services disabled and cxf packages >> > "forced-load" >> > >> > I haven't tried this. As I noted in the original email, I would imagine >> > that if this were deployed in Tomcat, and both CXF and Spring were >> included >> > in the application's WEB-INF/lib, this would not be an issue. I suspect >> > this would essentially give the same setup and I would imagine it would >> > work, but I would expect we'd lose the integration functionality in TomEE >> > (which we run the TCK against). Its also a big ask ask for anyone using >> > JAX-RS services, and just so happens to have Spring in their application, >> > as this did work ok in TomEE 9.1.2 (CXF 4.0.3). >> > >> > > If not it can just be to detect it in tomee and setup the webapp >> > properly? >> > >> > Can you give me some pointers on what you mean here? I'm happy to make >> > adjustments in TomEE, and equally happy to work on a suitable update for >> > CXF if preferred. >> > >> >> Like we detect the slf4j api is in the webapp or not to use the container >> or webapp binding it would be done the same for cxf/spring integration I >> suspect. >> Ideally I agree cxf should only use spring stuff if the bus is a spring one >> - it is ok to not use spring with cxf but have spring ;) - but tomee can >> likely workaround that. >> Something like loading the class SpringWebUtils in cxfrsservice#init method >> would be sufficient IMHO. >> >> >> > >> > Many thanks! >> > >> > Jon >> > >> > On Fri, May 17, 2024 at 3:56 AM Romain Manni-Bucau < >> rmannibu...@gmail.com> >> > wrote: >> > >> > > Hi Jon, >> > > >> > > Does it happen in the following both cases: >> > > >> > > * openejb.cxf.CxfContainerClassLoader is false >> > > * cxf is in the webapp, tomee cxf services disabled and cxf packages >> > > "forced-load" >> > > >> > > ? >> > > >> > > If not it can just be to detect it in tomee and setup the webapp >> > properly? >> > > >> > > Le jeu. 16 mai 2024 à 23:25, Andriy Redko a écrit : >> > > >> > >> Hey Jonathan, >> > >> >> > >> This is quite an interesting issue, is it possible to share (or point >> > out >> > >> to an example) small reproducer project for this problem? I think I >> > >> understand >> > >> what is happening but don't have a clear fix for that to suggest at >> the >> > >> moment. >> > >> >> > >> Thank you. >> > >> >> > >> Best Regards, >> > >> Andriy Redko >> > >> >> > >> > Hi, >> > >> >> > >> > Firstly, thank you for all the amazing work you do in CXF. I >> > >> participate in >> > >> > the Apache TomEE project, which includes CXF to enable TomEE to >> > provide >> > >> > REST and SOAP based services. >> > >> >> > >> > We've had a slightly unusual problem crop up that specifically >> affects >>
Re: Update CXF-9002 to resolved
Hi Jamie, Sure, done, thank you! Best Regards, Andriy Redko > Good morning/afternoon, > Can we update https://issues.apache.org/jira/browse/CXF-9002 to resolved? > The test suite no longer fails under IBM Java. > [INFO] > [INFO] --- > [INFO] T E S T S > [INFO] --- > [INFO] Running org.apache.cxf.systest.jaxrs.JAXRSMultithreadedClientTest > [INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 1.108 s -- in org.apache.cxf.systest.jaxrs.JAXRSMultithreadedClientTest > [INFO] > [INFO] Results: > [INFO] > [INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 > % git status > HEAD detached at apache/4.0.x-fixes > % mvn -version > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) > Maven home: /Users/jgoodyear/Documents/x1/maven/apache-maven-3.9.5 > Java version: 17.0.10, vendor: IBM Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk-17.0.10+7/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.4.1", arch: "aarch64", family: "mac" > Cheers, > Jamie
Re: SpringWebUtils in CXF in TomEE
Hey Jonathan, This is quite an interesting issue, is it possible to share (or point out to an example) small reproducer project for this problem? I think I understand what is happening but don't have a clear fix for that to suggest at the moment. Thank you. Best Regards, Andriy Redko > Hi, > Firstly, thank you for all the amazing work you do in CXF. I participate in > the Apache TomEE project, which includes CXF to enable TomEE to provide > REST and SOAP based services. > We've had a slightly unusual problem crop up that specifically affects > applications that expose Jakarta REST endpoints (through the included CXF > in TomEE), and include the Spring Framework in the application's > WEB-INF/lib. > The exception we see is: > java.lang.NoClassDefFoundError: > org/springframework/web/filter/ServerHttpObservationFilter > at > org.apache.cxf.jaxrs.springmvc.SpringWebUtils.setHttpRequestURI(SpringWebUtils.java:51) > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4] > at > org.apache.cxf.jaxrs.utils.HttpUtils.setHttpRequestURI(HttpUtils.java:380) > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4] > at > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.setExchangeProperties(JAXRSInInterceptor.java:246) > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4] > at > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:183) > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4] > at > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:78) > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > ~[cxf-core-4.0.4.jar:4.0.4] > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > ~[cxf-core-4.0.4.jar:4.0.4] > at > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) > ~[cxf-rt-transports-http-4.0.4.jar:4.0.4] > at > org.apache.openejb.server.cxf.rs.CxfRsHttpListener.doInvoke(CxfRsHttpListener.java:266) > ~[openejb-cxf-rs-9.1.3.jar:9.1.3] > at > org.apache.tomee.webservices.CXFJAXRSFilter.doFilter(CXFJAXRSFilter.java:99) > ~[tomee-jaxrs-9.1.3.jar:9.1.3] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185) > ~[catalina.jar:10.0.27] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158) > ~[catalina.jar:10.0.27] > at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) > ~[tomcat-websocket.jar:10.0.27] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185) > ~[catalina.jar:10.0.27] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158) > ~[catalina.jar:10.0.27] > at org.apache.openejb.server.httpd.EEFilter.doFilter(EEFilter.java:67) > ~[openejb-http-9.1.3.jar:9.1.3] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185) > ~[catalina.jar:10.0.27] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158) > ~[catalina.jar:10.0.27] > at > org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100) > ~[spring-web-6.0.19.jar:6.0.19] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116) > ~[spring-web-6.0.19.jar:6.0.19] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185) > ~[catalina.jar:10.0.27] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158) > ~[catalina.jar:10.0.27] > at > org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93) > ~[spring-web-6.0.19.jar:6.0.19] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116) > ~[spring-web-6.0.19.jar:6.0.19] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185) > ~[catalina.jar:10.0.27] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158) > ~[catalina.jar:10.0.27] > at > org.springframework.boot.web.servlet.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:124) > ~[spring-boot-3.1.11.jar:3.1.11] > at > org.springframework.boot.web.servlet.support.ErrorPageFilter$1.doFilterInternal(ErrorPageFilter.java:99) > ~[spring-boot-3.1.11.jar:3.1.11] > at > org.springframework.web.filter.OncePerRequestFilter.doF
Re: [PROPOSAL] Branch of 4.0.x, move main to 4.1.x (Jakarta EE 10)
Thanks a lot for replying folks! The main is now on 4.1.x / Jakarta EE 10. The Jenkins has been updated to have 4.0.x-fixes builds [1], the first 4.1.0-SNAPSHOTs are already available. The migration guide has started here as well [2], please contribute! Thanks folks! [1] https://ci-builds.apache.org/job/CXF/ [2] https://cwiki.apache.org/confluence/display/CXF20DOC/4.1+Migration+Guide Best Regards, Andriy Redko > +1. > Colm. > On Thu, Apr 11, 2024 at 1:20 PM Richard Zowalla wrote: >> Huge +1 from my side. >> We would be more than happy to start integrating a 4.1.0-SNAPSHOT in TomEE, >> so we get back to speed regarding EE10 efforts :) >> Thanks Andriy! >> Gruß >> Richard >> On 2024/04/11 12:08:19 Freeman Fang wrote: >>> +1 to move main branch to CXF 4.1.x, thanks Andriy! >>> Freeman >>> On Thu, Apr 11, 2024 at 7:48 AM Andriy Redko wrote: >>>> Hey Folks, >>>> I would like to resume the discussion regarding 4.1.x (Jakarta EE 10): the >>>> Jakarta EE 9.x was a transitional release, most (if not all) already >>>> jumped off. >>>> From the CXF side, quite a lot of work has been done already on 4.1.x >>>> (Jakarta EE 10), >>>> streamlining it would definitely help. So far only @Francesco responded >>>> (thanks a lot) >>>> but would be great to hear from others. Thanks! >>>> Best Regards, >>>> Andriy Redko >>>>> +1 thanks Andriy >>>>> Regards. >>>>> On 09/07/23 20:29, Andriy Redko wrote: >>>>>> Hey Folks, >>>>>>> The work on Jakarta EE 10 had started already (so far the progress >>>> was a bit slower >>>>>> than desired but the things should accelerate I hope). It becomes >>>> increasingly difficult >>>>>> to keep the separate pull request [1] intact (particularly, dependabot >>>> is constantly trying >>>>>> to update to latest specs). To ease the implementation efforts, I would >>>> like to propose >>>>>> to: >>>>>> - branch of 4.0.x-fixes from main >>>>>> - move main to 4.1.x >>>>>> - work on [1] to be ready for merge with main >>>>>> From the maintenance perspective, that would increase a bit the amount >>>> of work required: >>>>>> - 3.5.x and 3.6.x: those are the last (hopefully) branches for >>>> javax.* to maintain >>>>>> - 4.0.x and 4.1.x (upcoming): those are the ones to support going >>>> forward for jakarta.* to maintain >>>>>> Any feedback / thoughts / suggestions are very welcome! >>>>>> Thanks! >>>>>> [1] https://issues.apache.org/jira/browse/CXF-8671 >>>>>> [2] https://github.com/apache/cxf/pull/1201 >>>>>> Best Regards, >>>>>> Andriy Redko
Re: [PROPOSAL] Branch of 4.0.x, move main to 4.1.x (Jakarta EE 10)
Hey Folks, I would like to resume the discussion regarding 4.1.x (Jakarta EE 10): the Jakarta EE 9.x was a transitional release, most (if not all) already jumped off. From the CXF side, quite a lot of work has been done already on 4.1.x (Jakarta EE 10), streamlining it would definitely help. So far only @Francesco responded (thanks a lot) but would be great to hear from others. Thanks! Best Regards, Andriy Redko > +1 thanks Andriy > Regards. > On 09/07/23 20:29, Andriy Redko wrote: >> Hey Folks, >>> The work on Jakarta EE 10 had started already (so far the progress was a bit slower >> than desired but the things should accelerate I hope). It becomes >> increasingly difficult >> to keep the separate pull request [1] intact (particularly, dependabot is >> constantly trying >> to update to latest specs). To ease the implementation efforts, I would like >> to propose >> to: >> - branch of 4.0.x-fixes from main >> - move main to 4.1.x >> - work on [1] to be ready for merge with main >> From the maintenance perspective, that would increase a bit the amount of >> work required: >> - 3.5.x and 3.6.x: those are the last (hopefully) branches for javax.* to >> maintain >> - 4.0.x and 4.1.x (upcoming): those are the ones to support going forward >> for jakarta.* to maintain >> Any feedback / thoughts / suggestions are very welcome! >> Thanks! >> [1] https://issues.apache.org/jira/browse/CXF-8671 >> [2] https://github.com/apache/cxf/pull/1201 >> Best Regards, >> Andriy Redko
Re: [VOTE] - Release Apache CXF Fediz 1.6.2
+1, thanks Colm! Best Regards, Andriy Redko Thursday, March 21, 2024, 6:12:56 AM, you wrote: > This is a vote to release Apache CXF Fediz 1.6.2. It contains > dependency updates as well as a bug fix for a session timeout in newer > Tomcat instances https://issues.apache.org/jira/browse/FEDIZ-256 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecxf-1202/ > Git tag: https://github.com/apache/cxf-fediz/releases/tag/fediz-1.6.2 > +1 from me. > Colm.
Re: [VOTE] - Release Apache CXF XJC Utils 4.0.1 and 3.3.3
+1, thanks Colm! > This is a vote to release Apache CXF XJC Utils 4.0.1 and 3.3.3. They > both contain a fix for https://issues.apache.org/jira/browse/CXFXJC-44 > as well as various dependency updates. > 4.0.1: > Git tag: https://github.com/apache/cxf-xjc-utils/releases/tag/xjc-utils-4.0.1 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecxf-1200/ > 3.3.3: > Git tag: https://github.com/apache/cxf-xjc-utils/releases/tag/xjc-utils-3.3.3 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecxf-1201/ > +1 from me. > Colm.
Re: Plans for release 4.0.4?
+1, thanks Freeman! Folks, I will be off till next Friday (March, 8th), but I should have access to email, most of the day. Sorry about that. Best Regards, Andriy Redko Wednesday, February 28, 2024, 12:03:35 PM, you wrote: > Thanks for releasing Santuario and WSS4J Colm! > I think we shall release CXF 4.0.4 now. > @Daniel Kulp Could you please help release CXF 4.0.4? > Thanks so much! > Freeman > On Mon, Feb 19, 2024 at 5:42 AM Colm O hEigeartaigh > wrote: >> I've called a vote on Santuario today, so I'll try to release and get >> a WSS4J vote started by end of week. >> Colm. >> On Tue, Feb 13, 2024 at 11:09 PM Andriy Redko wrote: >>> Hi Colm, >>> I think it would be good to have a release soon-ish, but by and large, I >> don't think >>> we have hard deadline for it, please feel free to proceed as per your >> judgement. >>> Thank you. >>> Best Regards, >>> Andriy Redko >>>> Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I >>>> have time to do this and WSS4J before the next CXF release? >>>> Colm. >>>> On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang >> wrote: >>>>> Thanks Colm! >>>>> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh < cohei...@apache.org>>> wrote: >>>>>> Yes, I'll call a vote today on WSS4J 3.0.3. >>>>>> Colm. >>>>>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang >> wrote: >>>>>>> +1 to release Apache CXF 4.0.4 >>>>>>> @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release >> soon? >>>>>>> Thanks! >>>>>>> Freeman >>>>>>> On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek >> wrote: >>>>>>>> Hi, >>>>>>>> just for your information, the PR ( >> https://github.com/apache/cxf/pull/1660) >>>>>>>> requires version of wss4f to be 3.0.3 (to contain >>>>>>>> https://issues.apache.org/jira/browse/WSS-709) >>>>>>>> Best regards, >>>>>>>> Jiri >>>>>>>> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga >> wrote: >>>>>>>>> Thanks, great to hear that, Andriy. >>>>>>>>> It would be great if we could get >>>>>>>>> https://github.com/apache/cxf/pull/1660 merged in some form >> before the >>>>>>>>> release. >>>>>>>>> The main motivation is to be able to run CXF on FIPS-enabled >> systems. If >>>>>>>>> the customized algo suite, that the PR proposes, is questionable, >> I'd be >>>>>>>>> also fine with introducing a couple of new suites with fixed >>>>>>>>> non-standard names, like already done in the past for fixing >> CVEs. It >>>>>>>>> would be nice to hear other community members' thoughts. >>>>>>>>> Thanks again, >>>>>>>>> -- Peter >>>>>>>>> On 13/02/2024 02:35, Andriy Redko wrote: >>>>>>>>>> Hi Peter, >>>>>>>>>> Thanks a lot for reminding, I belive we are long overdue on >> that, @Dan, >>>>>>>>> @Colm >>>>>>>>>> may need your help please preparing the next release train (or >> any >>>>>>>>> objection folks)? >>>>>>>>>> Thank you! >>>>>>>>>> Best Regards, >>>>>>>>>> Andriy Redko >>>>>>>>>>> Hi, >>>>>>>>>>> we are preparing Quarkus CXF to release it for Quarkus 3.8 >> which is >>>>>>>>> going to be a LTS (Long Term Support) release. >>>>>>>>>>> I wonder whether we could count on getting CXF 4.0.4 by >> February 21st >>>>>>>>> to be able to use it in that release? >>>>>>>>>>> Thanks, >>>>>>>>>>> -- Peter >>>>>>>> -- >>>>>>>> Jiri Ondrusek >>>>>>>> Senior Software Engineer >>>>>>>> Red Hat Fuse
Re: Plans for release 4.0.4?
Thanks a lot, Colm! > I've called a vote on Santuario today, so I'll try to release and get > a WSS4J vote started by end of week. > Colm. > On Tue, Feb 13, 2024 at 11:09 PM Andriy Redko wrote: >> Hi Colm, >> I think it would be good to have a release soon-ish, but by and large, I >> don't think >> we have hard deadline for it, please feel free to proceed as per your >> judgement. >> Thank you. >> Best Regards, >> Andriy Redko >>> Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I >>> have time to do this and WSS4J before the next CXF release? >>> Colm. >>> On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang wrote: >>>> Thanks Colm! >>>> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh >>>> wrote: >>>>> Yes, I'll call a vote today on WSS4J 3.0.3. >>>>> Colm. >>>>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang >>>>> wrote: >>>>>> +1 to release Apache CXF 4.0.4 >>>>>> @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon? >>>>>> Thanks! >>>>>> Freeman >>>>>> On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek >>>>>> wrote: >>>>>>> Hi, >>>>>>> just for your information, the PR >>>>>>> (https://github.com/apache/cxf/pull/1660) >>>>>>> requires version of wss4f to be 3.0.3 (to contain >>>>>>> https://issues.apache.org/jira/browse/WSS-709) >>>>>>> Best regards, >>>>>>> Jiri >>>>>>> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga >>>>>>> wrote: >>>>>>>> Thanks, great to hear that, Andriy. >>>>>>>> It would be great if we could get >>>>>>>> https://github.com/apache/cxf/pull/1660 merged in some form before the >>>>>>>> release. >>>>>>>> The main motivation is to be able to run CXF on FIPS-enabled systems. >>>>>>>> If >>>>>>>> the customized algo suite, that the PR proposes, is questionable, I'd >>>>>>>> be >>>>>>>> also fine with introducing a couple of new suites with fixed >>>>>>>> non-standard names, like already done in the past for fixing CVEs. It >>>>>>>> would be nice to hear other community members' thoughts. >>>>>>>> Thanks again, >>>>>>>> -- Peter >>>>>>>> On 13/02/2024 02:35, Andriy Redko wrote: >>>>>>>>> Hi Peter, >>>>>>>>> Thanks a lot for reminding, I belive we are long overdue on that, >>>>>>>>> @Dan, >>>>>>>> @Colm >>>>>>>>> may need your help please preparing the next release train (or any >>>>>>>> objection folks)? >>>>>>>>> Thank you! >>>>>>>>> Best Regards, >>>>>>>>> Andriy Redko >>>>>>>>>> Hi, >>>>>>>>>> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is >>>>>>>> going to be a LTS (Long Term Support) release. >>>>>>>>>> I wonder whether we could count on getting CXF 4.0.4 by February 21st >>>>>>>> to be able to use it in that release? >>>>>>>>>> Thanks, >>>>>>>>>> -- Peter >>>>>>> -- >>>>>>> Jiri Ondrusek >>>>>>> Senior Software Engineer >>>>>>> Red Hat Fuse
Re: Plans for release 4.0.4?
Hi Colm, I think it would be good to have a release soon-ish, but by and large, I don't think we have hard deadline for it, please feel free to proceed as per your judgement. Thank you. Best Regards, Andriy Redko > Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I > have time to do this and WSS4J before the next CXF release? > Colm. > On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang wrote: >> Thanks Colm! >> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh >> wrote: >>> Yes, I'll call a vote today on WSS4J 3.0.3. >>> Colm. >>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang wrote: >>>> +1 to release Apache CXF 4.0.4 >>>> @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon? >>>> Thanks! >>>> Freeman >>>> On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek wrote: >>>>> Hi, >>>>> just for your information, the PR >>>>> (https://github.com/apache/cxf/pull/1660) >>>>> requires version of wss4f to be 3.0.3 (to contain >>>>> https://issues.apache.org/jira/browse/WSS-709) >>>>> Best regards, >>>>> Jiri >>>>> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga wrote: >>>>>> Thanks, great to hear that, Andriy. >>>>>> It would be great if we could get >>>>>> https://github.com/apache/cxf/pull/1660 merged in some form before the >>>>>> release. >>>>>> The main motivation is to be able to run CXF on FIPS-enabled systems. If >>>>>> the customized algo suite, that the PR proposes, is questionable, I'd be >>>>>> also fine with introducing a couple of new suites with fixed >>>>>> non-standard names, like already done in the past for fixing CVEs. It >>>>>> would be nice to hear other community members' thoughts. >>>>>> Thanks again, >>>>>> -- Peter >>>>>> On 13/02/2024 02:35, Andriy Redko wrote: >>>>>>> Hi Peter, >>>>>>> Thanks a lot for reminding, I belive we are long overdue on that, @Dan, >>>>>> @Colm >>>>>>> may need your help please preparing the next release train (or any >>>>>> objection folks)? >>>>>>> Thank you! >>>>>>> Best Regards, >>>>>>> Andriy Redko >>>>>>>> Hi, >>>>>>>> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is >>>>>> going to be a LTS (Long Term Support) release. >>>>>>>> I wonder whether we could count on getting CXF 4.0.4 by February 21st >>>>>> to be able to use it in that release? >>>>>>>> Thanks, >>>>>>>> -- Peter >>>>> -- >>>>> Jiri Ondrusek >>>>> Senior Software Engineer >>>>> Red Hat Fuse
Re: Plans for release 4.0.4?
Hi Peter, Thanks a lot for reminding, I belive we are long overdue on that, @Dan, @Colm may need your help please preparing the next release train (or any objection folks)? Thank you! Best Regards, Andriy Redko > Hi, > we are preparing Quarkus CXF to release it for Quarkus 3.8 which is going to > be a LTS (Long Term Support) release. > I wonder whether we could count on getting CXF 4.0.4 by February 21st to be > able to use it in that release? > Thanks, > -- Peter
Re: Apache CXF Netty Integration, URI not encoded
Hi Jochen, Thanks a lot for the contribution, we (maintainers) will take care of backporting once merged, thank you! Best Regards, Andriy Redko WJ> Hi Andriy, WJ> I did it WJ> https://github.com/apache/cxf/pull/1552 WJ> Can you please review and merge it? How does the downporting happen? WJ> Thanks and best regards WJ> Jochen WJ> -Original Message----- WJ> From: Andriy Redko WJ> Sent: Tuesday, 5 December 2023 03:49 WJ> To: Wilhelm, Jochen ; dev@cxf.apache.org WJ> Subject: Re: Apache CXF Netty Integration, URI not encoded WJ> Hi Jochen, WJ> Please feel free to submit the pull request, that would be WJ> much appreciated, thank you. WJ> Best Regards, WJ> Andriy Redko >> Hi Andriy, >> Thanks a lot, I was able to create a jria item >> https://issues.apache.org/jira/browse/CXF-8965 >> Should I also checkin the fix? Or will that be handled by someone else? >> Thanks and best regards >> Jochen >> -Original Message- >> From: Andriy Redko >> Sent: Monday, 4 December 2023 13:57 >> To: Wilhelm, Jochen ; dev@cxf.apache.org >> Subject: Re: Apache CXF Netty Integration, URI not encoded >> Hi Jochen, >> Sincere apologies, the request somehow slipped past our attention, I found >> and >> approved it, thank you. >> Best Regards, >> Andriy Redko >>> Hi Andriy, >>> Thanks for the confirmation, Unfortunately, I already requested access to >>> the JIRA, however, it is still pending for jochen.wilh...@sap.com >>> Thanks and best regards >>> Jochen >>> -Original Message- >>> From: Andriy Redko >>> Sent: Saturday, 2 December 2023 00:38 >>> To: Wilhelm, Jochen ; dev@cxf.apache.org >>> Subject: Re: Apache CXF Netty Integration, URI not encoded >>> [Sie erhalten nicht häufig E-Mails von drr...@gmail.com. Weitere >>> Informationen, warum dies wichtig ist, finden Sie unter >>> https://aka.ms/LearnAboutSenderIdentification ] >>> Hi Jochen, >>> I was able to reproduce the behavior you are seeing, I think this is the >>> issue and >>> you have been correctly pin-pointed the cause of it. Do you have an account >>> to create a >>> JIRA ticket here [1] (if not, I would be happy to help here). Thank you. >>> [1] https://issues.apache.org/jira/issues/ >>> Best Regards, >>> Andriy Redko >>>> Hi, >>>> We encountered an issue when using Apache CXF with Netty. It seems that >>>> URI encoding of pathes, e.g. containing whitespaces doesn’t work. >>>> We suspect >>>> org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest line 57 >>>> to be the problem. >>>> There the request uri is past but with uri.getPath() which decodes the >>>> URI, instead using uri.getRawPath() should be used. >>>> this.request = >>>> new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >>>>HttpMethod.valueOf(method), >>>>uri.getPath(), content); >>>> instead using >>>> this.request = >>>> new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >>>>HttpMethod.valueOf(method), >>>>uri.getRawPath(), content); >>>> Can you confirm this issue and the possible solution >>>> Thanks a lot >>>> Best regards >>>> Jochen Wilhelm >>>> Development Architect, Landscape Orchestration >>>> SAP SE Robert-Bosch-Strasse 30/34, 69190 Walldorf, Germany >>>> E: jochen.wilh...@sap.com >>>> T: +49622747723 >>>> Pflichtangaben/Mandatory Disclosure Statement: http://www.sap.com/impressum >>>> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige >>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich >>>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>>> Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte >>>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen >>>> Dank. >>>> This e-mail may contain trade secrets or privileged, undisclosed, or >>>> otherwise confidential information. If you have received this e-mail in >>>> error, you are hereby notified that any review, copying, or distribution >>>> of it is strictly prohibited. Please inform us immediately and destroy the >>>> original transmittal. Thank you for your cooperation. >>>> Public
Re: Apache CXF Netty Integration, URI not encoded
Hi Jochen, Please feel free to submit the pull request, that would be much appreciated, thank you. Best Regards, Andriy Redko > Hi Andriy, > Thanks a lot, I was able to create a jria item > https://issues.apache.org/jira/browse/CXF-8965 > Should I also checkin the fix? Or will that be handled by someone else? > Thanks and best regards > Jochen > -Original Message- > From: Andriy Redko > Sent: Monday, 4 December 2023 13:57 > To: Wilhelm, Jochen ; dev@cxf.apache.org > Subject: Re: Apache CXF Netty Integration, URI not encoded > Hi Jochen, > Sincere apologies, the request somehow slipped past our attention, I found and > approved it, thank you. > Best Regards, > Andriy Redko >> Hi Andriy, >> Thanks for the confirmation, Unfortunately, I already requested access to >> the JIRA, however, it is still pending for jochen.wilh...@sap.com >> Thanks and best regards >> Jochen >> -Original Message- >> From: Andriy Redko >> Sent: Saturday, 2 December 2023 00:38 >> To: Wilhelm, Jochen ; dev@cxf.apache.org >> Subject: Re: Apache CXF Netty Integration, URI not encoded >> [Sie erhalten nicht häufig E-Mails von drr...@gmail.com. Weitere >> Informationen, warum dies wichtig ist, finden Sie unter >> https://aka.ms/LearnAboutSenderIdentification ] >> Hi Jochen, >> I was able to reproduce the behavior you are seeing, I think this is the >> issue and >> you have been correctly pin-pointed the cause of it. Do you have an account >> to create a >> JIRA ticket here [1] (if not, I would be happy to help here). Thank you. >> [1] https://issues.apache.org/jira/issues/ >> Best Regards, >> Andriy Redko >>> Hi, >>> We encountered an issue when using Apache CXF with Netty. It seems that URI >>> encoding of pathes, e.g. containing whitespaces doesn’t work. >>> We suspect >>> org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest line 57 >>> to be the problem. >>> There the request uri is past but with uri.getPath() which decodes the URI, >>> instead using uri.getRawPath() should be used. >>> this.request = >>> new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >>> HttpMethod.valueOf(method), >>> uri.getPath(), content); >>> instead using >>> this.request = >>> new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >>> HttpMethod.valueOf(method), >>> uri.getRawPath(), content); >>> Can you confirm this issue and the possible solution >>> Thanks a lot >>> Best regards >>> Jochen Wilhelm >>> Development Architect, Landscape Orchestration >>> SAP SE Robert-Bosch-Strasse 30/34, 69190 Walldorf, Germany >>> E: jochen.wilh...@sap.com >>> T: +49622747723 >>> Pflichtangaben/Mandatory Disclosure Statement: http://www.sap.com/impressum >>> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige >>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich >>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>> Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte >>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen >>> Dank. >>> This e-mail may contain trade secrets or privileged, undisclosed, or >>> otherwise confidential information. If you have received this e-mail in >>> error, you are hereby notified that any review, copying, or distribution of >>> it is strictly prohibited. Please inform us immediately and destroy the >>> original transmittal. Thank you for your cooperation. >>> Public
Re: Apache CXF Netty Integration, URI not encoded
Hi Jochen, Sincere apologies, the request somehow slipped past our attention, I found and approved it, thank you. Best Regards, Andriy Redko WJ> Hi Andriy, WJ> Thanks for the confirmation, Unfortunately, I already requested access to the JIRA, however, it is still pending for jochen.wilh...@sap.com WJ> Thanks and best regards WJ> Jochen WJ> -Original Message- WJ> From: Andriy Redko WJ> Sent: Saturday, 2 December 2023 00:38 WJ> To: Wilhelm, Jochen ; dev@cxf.apache.org WJ> Subject: Re: Apache CXF Netty Integration, URI not encoded WJ> [Sie erhalten nicht häufig E-Mails von drr...@gmail.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] WJ> Hi Jochen, WJ> I was able to reproduce the behavior you are seeing, I think this is the issue and WJ> you have been correctly pin-pointed the cause of it. Do you have an account to create a WJ> JIRA ticket here [1] (if not, I would be happy to help here). Thank you. WJ> [1] https://issues.apache.org/jira/issues/ WJ> Best Regards, WJ> Andriy Redko >> Hi, >> We encountered an issue when using Apache CXF with Netty. It seems that URI >> encoding of pathes, e.g. containing whitespaces doesn’t work. >> We suspect org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest >> line 57 to be the problem. >> There the request uri is past but with uri.getPath() which decodes the URI, >> instead using uri.getRawPath() should be used. >> >> this.request = >> new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >>HttpMethod.valueOf(method), >>uri.getPath(), content); >> >> instead using >> >> this.request = >> new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >>HttpMethod.valueOf(method), >>uri.getRawPath(), content); >> >> >> >> Can you confirm this issue and the possible solution >> >> Thanks a lot >> >> Best regards >> >> Jochen Wilhelm >> Development Architect, Landscape Orchestration >> SAP SE Robert-Bosch-Strasse 30/34, 69190 Walldorf, Germany >> E: jochen.wilh...@sap.com >> T: +49622747723 >> >> Pflichtangaben/Mandatory Disclosure Statement: http://www.sap.com/impressum >> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige >> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich >> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >> Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte >> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen >> Dank. >> This e-mail may contain trade secrets or privileged, undisclosed, or >> otherwise confidential information. If you have received this e-mail in >> error, you are hereby notified that any review, copying, or distribution of >> it is strictly prohibited. Please inform us immediately and destroy the >> original transmittal. Thank you for your cooperation. >> >> Public
Re: Apache CXF Netty Integration, URI not encoded
Hi Jochen, I was able to reproduce the behavior you are seeing, I think this is the issue and you have been correctly pin-pointed the cause of it. Do you have an account to create a JIRA ticket here [1] (if not, I would be happy to help here). Thank you. [1] https://issues.apache.org/jira/issues/ Best Regards, Andriy Redko > Hi, > We encountered an issue when using Apache CXF with Netty. It seems that URI > encoding of pathes, e.g. containing whitespaces doesn’t work. > We suspect org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest > line 57 to be the problem. > There the request uri is past but with uri.getPath() which decodes the URI, > instead using uri.getRawPath() should be used. > > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getPath(), content); > > instead using > > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getRawPath(), content); > > > > Can you confirm this issue and the possible solution > > Thanks a lot > > Best regards > > Jochen Wilhelm > Development Architect, Landscape Orchestration > SAP SE Robert-Bosch-Strasse 30/34, 69190 Walldorf, Germany > E: jochen.wilh...@sap.com > T: +49622747723 > > Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum > Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich > erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine > Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte > benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. > This e-mail may contain trade secrets or privileged, undisclosed, or > otherwise confidential information. If you have received this e-mail in > error, you are hereby notified that any review, copying, or distribution of > it is strictly prohibited. Please inform us immediately and destroy the > original transmittal. Thank you for your cooperation. > > Public
Re: Apache CXF Netty Integration, URI not encoded
Hi Jochen, I was able to reproduce the behavior you are seeing, I think this is the issue and you have been correctly pin-pointed the cause of it. Do you have an account to create a JIRA ticket here [1] (if not, I would be happy to help here). Thank you. [1] https://issues.apache.org/jira/issues/ Best Regards, Andriy Redko > Hi, > We encountered an issue when using Apache CXF with Netty. It seems that URI > encoding of pathes, e.g. containing whitespaces doesn’t work. > We suspect org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest > line 57 to be the problem. > There the request uri is past but with uri.getPath() which decodes the URI, > instead using uri.getRawPath() should be used. > > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >HttpMethod.valueOf(method), >uri.getPath(), content); > > instead using > > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, >HttpMethod.valueOf(method), >uri.getRawPath(), content); > > > > Can you confirm this issue and the possible solution > > Thanks a lot > > Best regards > > Jochen Wilhelm > Development Architect, Landscape Orchestration > SAP SE Robert-Bosch-Strasse 30/34, 69190 Walldorf, Germany > E: jochen.wilh...@sap.com > T: +49622747723 > > Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum > Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich > erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine > Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte > benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. > This e-mail may contain trade secrets or privileged, undisclosed, or > otherwise confidential information. If you have received this e-mail in > error, you are hereby notified that any review, copying, or distribution of > it is strictly prohibited. Please inform us immediately and destroy the > original transmittal. Thank you for your cooperation. > > Public
Re: Question on WS-Addressing Licensing
Hi Karsten, I've just got the response from Eclipse folks, check [1] please, thank you. [1] https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2369#note_1391368 Best Regards, Andriy Redko KK> Hi Andriy, KK> any news? We require a response on the given question. KK> Do you recommend creating an issue? KK> Kind regards, KK> Karsten KK> On 08.11.2023, 00:54, "Andriy Redko" mailto:drr...@gmail.com>> wrote: KK> Hi Karsten, KK> This is really good question, I was trying to go over the commit history but KK> sadly there no details regarding licensing (or source(s) of the files in question). KK> However, I have found an interesting reference on Eclipse Gitlab [1] regarding KK> these licenses, may be we could contact their IP team to find out more KK> information? (TLDR; the licenses were reviewed and approved by IP Team). KK> @Dan do you have any insights? KK> Thank you. KK> [1] https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2369 <https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2369> KK> Best Regards, KK> Andriy Redko KK>> Hi all! KK>> We are currently working ourselves through some license scanner identifications. The policy we are trying to accommodate our software (which uses CXF) to has rather strict license requirements. KK>> Specifically we currently look at KK>> https://github.com/apache/cxf/blob/main/core/src/main/resources/schemas/wsdl/addressing.xsd <https://github.com/apache/cxf/blob/main/core/src/main/resources/schemas/wsdl/addressing.xsd> KK>> We refer to the terms as covered by the header as KK>> WS-Addressing Specification License KK>> In scancode the license is known under the id ws-addressing-spec: KK>> https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/ws-addressing-spec.LICENSE <https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/ws-addressing-spec.LICENSE> KK>> While scancode indicates a permissive license here. The policy we try to adhere to indicates that this license only grants permission for the prupose of development and evaluation: KK>> Permission to copy, display, perform, modify and distribute the WS-Addressing KK>> Specification, and to authorize others to do the foregoing, in any medium KK>> without fee or royalty is hereby granted for the purpose of developing and KK>> evaluating the WS-Addressing Specification. KK>> Could you please elaborate on how the Apache Foundation / CXF assesses this license? KK>> Is there any background information that this license does not interfere with a general distribution and use of the schema as part of cxf-core.jar? KK>> Any details and/or pointers regarding this topic are highly appreciated. KK>> In case, could you please also elaborate on KK>> https://github.com/apache/cxf/blob/main/core/src/main/resources/schemas/wsdl/addressing200403.xsd <https://github.com/apache/cxf/blob/main/core/src/main/resources/schemas/wsdl/addressing200403.xsd> KK>> Under which license terms do you regard this file being distributed as part of CXF? KK>> Sorry for boiling up aspects that are in the codebase since decades. We just need good arguments why things work. KK>> Kind regards, KK>> Karsten KK>> Licenses identified in the schema folder of cxf-core-3.5.5.jar: >>>>> Permission Terms (variant 070) <<< KK>> /schemas/wsdl/http.xsd KK>> /schemas/wsdl/mime-binding.xsd KK>> /schemas/wsdl/soap-binding.xsd KK>> /schemas/wsdl/wsdl.xsd >>>>> Permission Terms (variant 072) <<< KK>> /schemas/wsdl/soap12-binding.xsd >>>>> W3C Software Notice and License (1998-07-20) <<< KK>> /schemas/wsdl/soap-encoding.xsd >>>>> W3C Software Notice and License (2002-12-31) <<< KK>> /schemas/wsdl/ws-addr-wsdl.xsd KK>> /schemas/wsdl/ws-addr.xsd >>>>> WS Reliable Messaging License <<< KK>> /schemas/wsdl/wsrm.xsd >>>>> WS-Addressing Specification License <<< KK>> /schemas/wsdl/addressing.xsd
Re: Apache CXF JAXRS Logging questions
Hi Jean,
I think you could do something like that:
Attachment att = new AttachmentBuilder()
.id("root")
.contentDisposition(root))
.mediaType("text/csv")
.object(Dossier.toCSV(dossiers))
.build()
(I would assume Dossier.toCSV(dossiers) returns a String).
Thank you.
Best Regards,
Andriy Redko
JPU> Hi Andriy,
JPU> Currently I create the attachment like:
JPU> ContentDisposition cd = new
JPU> ContentDisposition("form-data;name=file-0;filename="+filename);
JPU> InputStream is = new
JPU>
ByteArrayInputStream(Dossier.toCSV(dossiers).getBytes(StandardCharsets.UTF_8));
JPU> Attachment att = new Attachment("root",is, cd);
JPU> Although this work (i.e. is accepted by the server) it is not the
JPU> appropriate way to generate an Attachment containing a csv file as readable
JPU> characters.
JPU> The API docs refer to using
JPU> org.apache.cxf.jaxrs.ext.multipart.AttachmentBuilder but the constructors
JPU> don't give much information.
JPU> So what would be an appropriate way to send a csv-file that would get
JPU> logged?
JPU> Regards,
JPU> J.P. Urkens
JPU> -Original Message-
JPU> From: Andriy Redko
JPU> Sent: zondag 12 november 2023 17:15
JPU> To: Jean Pierre URKENS ;
dev@cxf.apache.org
JPU> Subject: Re: Apache CXF JAXRS Logging questions
JPU> Hi Jean,
JPU> Getting back to you with the multipart logging, there are 2 parts to it:
the
JPU> message content-type and boundary content-type. The message content type is
JPU> indeed multipart and is logged but it seems like the boundary content type
JPU> (uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b) is binary, this is why it is
JPU> logged as suppressed (binary boundary content is not logged, as per
JPU> AbstractLoggingInterceptor::stripBinaryParts).
JPU> Hope it helps, thank you.
JPU> Best Regards,
JPU> Andriy Redko
>> Hi Andriy,
>> When sending a multipart/form-data request to a service endpoint I see the
>> following in the message log:
>> 2023-11-10 13:27:37,578 [T8N1TP1-4] INFO
>> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
>> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) - REQ_OUT
>> Address: http://L-P53-008:8085/dosis-server/csv
>> HttpMethod: POST
>> Content-Type: multipart/form-data;charset=UTF-8;
>> boundary="uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b"
>> ExchangeId: d87098e4-fe86-4a42-8985-37a6ccc90b1d
>> Headers: {Authorization=Bearer 11a5b872-be3f-49f8-a26f-fbeb9be56a66,
>> Accept=*/*}
>> Payload:
>> --uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b
>> --- Content suppressed ---
>> uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b
>> 2023-11-10 13:27:37,661 [T8N1TP1-4] INFO
>> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
>> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) - RESP_IN
>> Address: http://L-P53-008:8085/dosis-server/csv
>> ResponseCode: 200
>> ExchangeId: d87098e4-fe86-4a42-8985-37a6ccc90b1d
>> Headers: {transfer-encoding=chunked, Date=Fri, 10 Nov 2023
>> 12:27:37 GMT} I.e. the logging of the multipart form-data gets suppressed.
>> I tried enabling it by setting the LoggingFeature (although according to
>> the Javadoc ‘logMultipart defaults to true’) on the JAXRSClientFactoryBean
>> e.g.:
>> public Response dossiersOpladen(List dossiers, String
>> filename) throws GeneralSecurityException, AuthorizationException,
>> DosisCommunicationException, BusinessException {
>> try {
>> //Create the web client
>> String baseAddress =
>> Configuration.getInstance().getItem("dosis.service.base.uri");
>> clientProxy =
>> getThreadsafeProxy(baseAddress+"/csv");
>> Client client = WebClient.client(clientProxy);
>> WebClient webClient =
>> WebClient.fromClient(client);
>>
>> WebClient.getConfig(webClient).getHttpConduit().getClient().setReceiveTimeout(6L);
>>
>> webClient.type(MediaType.MULTIPART_FORM_DATA_TYPE.withCharset(Standard
>> Charsets.UTF_8.name()));
>>
>> //Authorize API client by adding an appropriate
>> authorization header
>> authorizationHandler.authorize(webClient);
>>
>> //POST the request
>> log.info("Uploading dossiers from csv");
>> ContentDisposition cd = new
>> ContentD
Re: Apache CXF JAXRS Logging questions
Hi Jean,
Thanks a lot for the update, I think it is a viable option for
your context, thank you.
Best Regards,
Andriy Redko
JPU> Hi Andriy,
JPU> I couldn't get filtering to work correctly since I didn't know the correct
JPU> name of the Logger category within which the REQ/RESP message is logged.
JPU> But checking the event data showed the logger category and they all have a
JPU> naming like ' log4j.logger.org.apache.cxf.services.'. So
JPU> basically I can do:
JPU> log4j.additivity.org.apache.cxf.services=false
JPU> log4j.logger.org.apache.cxf.services.=INFO,
JPU> where:
JPU>Is the name of the interface (i.e. of
JAX-RSclient) or the
JPU> implementation (in case of a JAX-RS service endpoint) class
JPU> The name of the appender where to log the
REQ/RESP message
JPU> Knowing the exact logger category makes the use of a filter obsolete.
JPU> Regards,
JPU> J.P. Urkens
JPU> -Original Message-
JPU> From: Jean Pierre URKENS
JPU> Sent: maandag 13 november 2023 9:19
JPU> To: 'Andriy Redko' ; 'dev@cxf.apache.org'
JPU>
JPU> Subject: RE: Apache CXF JAXRS Logging questions
JPU> Hi Andriy,
JPU> Unfortunately it is a legacy application which is still using log4j v1.x. I
JPU> don't think it supports scripting but it does have some filtering
JPU> capabilities, maybe I could use org.apache.log4j.varia.StringMatchFilter
for
JPU> this purpose.
JPU> It will check the event.getRenderedMessage() of a 'string to match'. If a
JPU> match is found the log event can either be accepted or denied:
JPU>public int decide(LoggingEvent event) {
JPU> String msg = event.getRenderedMessage();
JPU> if (msg == null || stringToMatch == null)
JPU> return Filter.NEUTRAL;
JPU> if (msg.indexOf(stringToMatch) == -1) {
JPU> return Filter.NEUTRAL;
JPU> } else { // we've got a match
JPU> if (acceptOnMatch) {
JPU> return Filter.ACCEPT;
JPU> } else {
JPU> return Filter.DENY;
JPU> }
JPU> }
JPU> }
JPU> However I've no idea how the Apache CXF Log event looks like. Does the
JPU> event.getRenderedMessage() contains the hostname of the target endpoint? If
JPU> so I could 'string match' on that.
JPU> I am giving it a try and let you know the result.
JPU> Regards,
JPU> J.P. Urkens
JPU> -Original Message-
JPU> From: Andriy Redko
JPU> Sent: zaterdag 11 november 2023 3:31
JPU> To: Jean Pierre URKENS ;
dev@cxf.apache.org
JPU> Subject: Re: Apache CXF JAXRS Logging questions
JPU> Hi Jean,
JPU> Hm, the logMultipart is indeed enabled by default and should lead to
message
JPU> content being logged, looks like a bug, I will try to reproduce it (my
JPU> apologies, haven't had time for that). I will get back to you on this
JPU> subject.
JPU> Regarding your other question, is it possible to get REST messages for
JPU> different endpoints to be logged to different files, I believe the
JPU> AbstractLoggingInterceptor has no support for that but I think you could
use
JPU> Log4j scripting capabilities [1] to select the right appender based on log
JPU> event properties (fe address which is somewhat equivalent to endpoint).
JPU> [1] https://logging.apache.org/log4j/2.x/manual/configuration.html
JPU> Thank you.
JPU> Best Regards,
JPU> Andriy Redko
JPU>> Apache CXF JAXRS Logging questions
JPU>> Hi Andriy,
JPU>> When sending a multipart/form-data request to a service endpoint I
JPU>> see the following in the message log:
JPU>>2023-11-10 13:27:37,578 [T8N1TP1-4] INFO
JPU>> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
JPU>> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) -
JPU>> REQ_OUT
JPU>> Address: *http://L-P53-008:8085/dosis-server/csv*
JPU>> <http://L-P53-008:8085/dosis-server/csv>
JPU>> HttpMethod: POST
JPU>> Content-Type: multipart/form-data;charset=UTF-8;
JPU>> boundary="uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b"
JPU>> ExchangeId: d87098e4-fe86-4a42-8985-37a6ccc90b1d
JPU>> Headers: {Authorization=Bearer
JPU>> 11a5b872-be3f-49f8-a26f-fbeb9be56a66, Accept=*/*}
JPU>> Payload:
JPU>> *--uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b*
JPU>> *--- Content suppressed ---*
JPU>> *uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b*
JPU>> 2023-11-10 13:27:37,661 [T8N1TP1-4] INFO
JPU>> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
JPU>> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) -
JPU>> RESP_IN
JPU>> Address: *http://L-P53-008:80
Re: Apache CXF JAXRS Logging questions
Hi Jean,
Getting back to you with the multipart logging, there are 2 parts to it: the
message content-type
and boundary content-type. The message content type is indeed multipart and is
logged but it seems like the
boundary content type (uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b) is binary,
this is why it is
logged as suppressed (binary boundary content is not logged, as per
AbstractLoggingInterceptor::stripBinaryParts).
Hope it helps, thank you.
Best Regards,
Andriy Redko
> Hi Andriy,
> When sending a multipart/form-data request to a service endpoint I see the
> following in the message log:
> 2023-11-10 13:27:37,578 [T8N1TP1-4] INFO
> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) - REQ_OUT
> Address: http://L-P53-008:8085/dosis-server/csv
> HttpMethod: POST
> Content-Type: multipart/form-data;charset=UTF-8;
> boundary="uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b"
> ExchangeId: d87098e4-fe86-4a42-8985-37a6ccc90b1d
> Headers: {Authorization=Bearer 11a5b872-be3f-49f8-a26f-fbeb9be56a66,
> Accept=*/*}
> Payload:
> --uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b
> --- Content suppressed ---
> uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b
> 2023-11-10 13:27:37,661 [T8N1TP1-4] INFO
> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) - RESP_IN
> Address: http://L-P53-008:8085/dosis-server/csv
> ResponseCode: 200
> ExchangeId: d87098e4-fe86-4a42-8985-37a6ccc90b1d
> Headers: {transfer-encoding=chunked, Date=Fri, 10 Nov 2023 12:27:37 GMT}
> I.e. the logging of the multipart form-data gets suppressed. I tried enabling
> it by setting the LoggingFeature (although according to the Javadoc
> ‘logMultipart defaults to true’) on the JAXRSClientFactoryBean e.g.:
> public Response dossiersOpladen(List dossiers, String
> filename) throws GeneralSecurityException, AuthorizationException,
> DosisCommunicationException, BusinessException {
> try {
> //Create the web client
> String baseAddress =
> Configuration.getInstance().getItem("dosis.service.base.uri");
> clientProxy = getThreadsafeProxy(baseAddress+"/csv");
> Client client = WebClient.client(clientProxy);
> WebClient webClient = WebClient.fromClient(client);
>
> WebClient.getConfig(webClient).getHttpConduit().getClient().setReceiveTimeout(6L);
>
> webClient.type(MediaType.MULTIPART_FORM_DATA_TYPE.withCharset(StandardCharsets.UTF_8.name()));
>
> //Authorize API client by adding an appropriate
> authorization header
> authorizationHandler.authorize(webClient);
>
> //POST the request
> log.info("Uploading dossiers from csv");
> ContentDisposition cd = new
> ContentDisposition("form-data;name=file-0;filename="+filename);
> InputStream is = new
> ByteArrayInputStream(Dossier.toCSV(dossiers).getBytes(StandardCharsets.UTF_8));
> Attachment att = new Attachment("root",is, cd);
> return webClient.post(new MultipartBody(att));
> } catch (JsonProcessingException e) {
> throw new BusinessException("Exception using REST
> service: "+e.getMessage(),e);
> }
> }
> private static DosisService getThreadsafeProxy(String baseAddress)
> throws GeneralSecurityException {
> JacksonJsonProvider jjProvider = new JacksonJsonProvider(new
> CustomObjectMapper());
> List providers = Arrays.asList(new
> MultipartProvider(), jjProvider);
>
> final JAXRSClientFactoryBean factory = new
> JAXRSClientFactoryBean();
> factory.setAddress(baseAddress);
> factory.setServiceClass(DosisService.class);
> factory.setProviders(providers);
> factory.getOutInterceptors().add(new LoggingOutInterceptor());
> factory.getInInterceptors().add(new LoggingInInterceptor());
> factory.setThreadSafe(true);
>
> LoggingFeature feature = new LoggingFeature();
> feature.setLogMultipart(true);
> feature.setLogBinary(true);
> factory.setFeatures(Arrays.asList(feature));
> DosisService api = fact
Re: Apache CXF JAXRS Logging questions
Hi Jean,
Hm, the logMultipart is indeed enabled by default and should lead to message
content being logged, looks like a bug, I will try to reproduce it (my
apologies,
haven't had time for that). I will get back to you on this subject.
Regarding your other question, is it possible to get REST messages for
different endpoints
to be logged to different files, I believe the AbstractLoggingInterceptor has
no support
for that but I think you could use Log4j scripting capabilities [1] to select
the right
appender based on log event properties (fe address which is somewhat equivalent
to
endpoint).
[1] https://logging.apache.org/log4j/2.x/manual/configuration.html
Thank you.
Best Regards,
Andriy Redko
JPU> Apache CXF JAXRS Logging questions
JPU> Hi Andriy,
JPU> When sending a multipart/form-data request to a service endpoint I see the
JPU> following in the message log:
JPU>2023-11-10 13:27:37,578 [T8N1TP1-4] INFO
JPU> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
JPU> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) - REQ_OUT
JPU> Address: *http://L-P53-008:8085/dosis-server/csv*
JPU> <http://L-P53-008:8085/dosis-server/csv>
JPU> HttpMethod: POST
JPU> Content-Type: multipart/form-data;charset=UTF-8;
JPU> boundary="uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b"
JPU> ExchangeId: d87098e4-fe86-4a42-8985-37a6ccc90b1d
JPU> Headers: {Authorization=Bearer
JPU> 11a5b872-be3f-49f8-a26f-fbeb9be56a66, Accept=*/*}
JPU> Payload:
JPU> *--uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b*
JPU> *--- Content suppressed ---*
JPU> *uuid:4ee36a2e-8382-4ef8-878b-0aedcab77c3b*
JPU> 2023-11-10 13:27:37,661 [T8N1TP1-4] INFO
JPU> (SID=D04AF2A21B0DCEFFE4724AEF745B5BDF)
JPU> (org.apache.cxf.ext.logging.slf4j.Slf4jEventSender:84) - RESP_IN
JPU> Address: *http://L-P53-008:8085/dosis-server/csv*
JPU> <http://L-P53-008:8085/dosis-server/csv>
JPU> ResponseCode: 200
JPU> ExchangeId: d87098e4-fe86-4a42-8985-37a6ccc90b1d
JPU> Headers: {transfer-encoding=chunked, Date=Fri, 10 Nov 2023
JPU> 12:27:37 GMT}
JPU> I.e. the logging of the multipart form-data gets suppressed. I tried
JPU> enabling it by setting the LoggingFeature (although according to the
JPU> Javadoc ‘logMultipart defaults to true’) on the JAXRSClientFactoryBean
e.g.:
JPU>* public* Response* dossiersOpladen*(List dossiers, String
JPU> filename)* throws* GeneralSecurityException, AuthorizationException,
JPU> DosisCommunicationException, BusinessException {
JPU>* try* {
JPU> //Create the web client
JPU> String* baseAddress* = Configuration.*getInstance*
JPU> ().*getItem**(**"dosis.service.base.uri"**)*;
JPU>* clientProxy* =* getThreadsafeProxy*(baseAddress+
JPU> "/csv");
JPU> Client* client* =
WebClient.*client*(*clientProxy*);
JPU> WebClient* webClient* = WebClient.*fromClient*
JPU> (client);
JPU> WebClient.*getConfig*
JPU> (webClient).getHttpConduit().getClient().setReceiveTimeout(6L);
JPU> webClient.type(MediaType.*MULTIPART_FORM_DATA_TYPE*
JPU> .withCharset(StandardCharsets.*UTF_8*.name()));
JPU> //Authorize API client by adding an appropriate
JPU> authorization header
JPU> authorizationHandler.authorize(webClient);
JPU> //POST the request
JPU>* log*.info("Uploading dossiers from csv");
JPU> ContentDisposition* cd* =* new* ContentDisposition(
JPU> "form-data;name=file-0;filename="+filename);
JPU> InputStream* is* =* new*
JPU> ByteArrayInputStream(Dossier.*toCSV*(dossiers).getBytes(StandardCharsets.
JPU> *UTF_8*));
JPU> Attachment* att* =* new* Attachment("root",is, cd);
JPU>* return* webClient.post(*new* MultipartBody(att));
JPU> }* catch* (JsonProcessingException* e*) {
JPU>* throw** new* BusinessException("Exception using
JPU> REST service: "+e.getMessage(),e);
JPU> }
JPU> }
JPU>* private** static* DosisService* getThreadsafeProxy*(String
JPU> baseAddress)* throws* GeneralSecurityException {
JPU> JacksonJsonProvider* jjProvider* =* new*
JPU> JacksonJsonProvider(*new* CustomObjectMapper());
JPU> List* providers* = Arrays.*asList*(*new*
JPU> MultipartProvider(), jjProvid
Re: Question on WS-Addressing Licensing
Hi Karsten, This is really good question, I was trying to go over the commit history but sadly there no details regarding licensing (or source(s) of the files in question). However, I have found an interesting reference on Eclipse Gitlab [1] regarding these licenses, may be we could contact their IP team to find out more information? (TLDR; the licenses were reviewed and approved by IP Team). @Dan do you have any insights? Thank you. [1] https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2369 Best Regards, Andriy Redko KK> Hi all! KK> We are currently working ourselves through some license scanner identifications. The policy we are trying to accommodate our software (which uses CXF) to has rather strict license requirements. KK> Specifically we currently look at KK> https://github.com/apache/cxf/blob/main/core/src/main/resources/schemas/wsdl/addressing.xsd KK> We refer to the terms as covered by the header as KK> WS-Addressing Specification License KK> In scancode the license is known under the id ws-addressing-spec: KK> https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/ws-addressing-spec.LICENSE KK> While scancode indicates a permissive license here. The policy we try to adhere to indicates that this license only grants permission for the prupose of development and evaluation: KK> Permission to copy, display, perform, modify and distribute the WS-Addressing KK> Specification, and to authorize others to do the foregoing, in any medium KK> without fee or royalty is hereby granted for the purpose of developing and KK> evaluating the WS-Addressing Specification. KK> Could you please elaborate on how the Apache Foundation / CXF assesses this license? KK> Is there any background information that this license does not interfere with a general distribution and use of the schema as part of cxf-core.jar? KK> Any details and/or pointers regarding this topic are highly appreciated. KK> In case, could you please also elaborate on KK> https://github.com/apache/cxf/blob/main/core/src/main/resources/schemas/wsdl/addressing200403.xsd KK> Under which license terms do you regard this file being distributed as part of CXF? KK> Sorry for boiling up aspects that are in the codebase since decades. We just need good arguments why things work. KK> Kind regards, KK> Karsten KK> Licenses identified in the schema folder of cxf-core-3.5.5.jar: >>>> Permission Terms (variant 070) <<< KK> /schemas/wsdl/http.xsd KK> /schemas/wsdl/mime-binding.xsd KK> /schemas/wsdl/soap-binding.xsd KK> /schemas/wsdl/wsdl.xsd >>>> Permission Terms (variant 072) <<< KK> /schemas/wsdl/soap12-binding.xsd >>>> W3C Software Notice and License (1998-07-20) <<< KK> /schemas/wsdl/soap-encoding.xsd >>>> W3C Software Notice and License (2002-12-31) <<< KK> /schemas/wsdl/ws-addr-wsdl.xsd KK> /schemas/wsdl/ws-addr.xsd >>>> WS Reliable Messaging License <<< KK> /schemas/wsdl/wsrm.xsd >>>> WS-Addressing Specification License <<< KK> /schemas/wsdl/addressing.xsd
Re: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up
Greetings David, Thanks a lot for the updates! As per your request, on behalf of Apache CXF project I would like to confirm that JDK-21 is already fully supported. Thank you! Best Regards, Andriy Redko > Greetings! > JDK 21 has been released (General Availability) on September 19th as planned. > You can find "The Arrival of Java 21" announcement here [1], and some > additional Java 21 materials in the "Topics of Interest" section below. On > behalf of the entire Java team, let me send our thanks to all of you. Through > your active participation in this program, you are helping shape the Java > platform! > Needless to say, that Java 21 is an important release, so may I ask you to > send me a brief email with the Java 21 support status of your project(s): > Already supported - Plan to support short-term - Don't plan to support > short-term ? > And now that JDK 21 is out, let's shift our attention to JDK 22 which will > enter the Rampdown Phase in less than 50 days on December 7 [2]. > I want to conclude this update by briefly mentioning three different > initiatives to are relevant to this group as they are, in their own way and > at various levels, contributing to adopt newer Java releases more rapidly: > the Class-File API, Oracle's Java Platform extension for VS Code, and the > Java Playground. > ### The Class-File API > The Class-File API is a new standard API for parsing, generating, and > transforming Java class files. One of its unique aspects is that it will > co-evolve with the class-file format, which overtime will greatly reduce the > friction of implementing new class-file features. With the fast-paced > evolution of the Java platform, this was much-needed. This API should soon be > previewed and as it matures, we expect the JDK to switch from using various > custom class-file libraries to this standard API. We also expect that > overtime frameworks relying on bytecode manipulation will also benefit from > using this new JDK class-file library. For more information, please check > this recent Newscast [3] for an overview, Brian Goetz's JVMLS session [4] for > more details and design considerations, and JEP 457: Class-File API (Preview) > [5] for the technical details. > ### Oracle's Java Platform extension for Visual Studio Code > Oracle has just announced [6] a new Visual Studio Code extension for Java > developers. Unlike other VS Code extensions, this new extension is using > under the hood the `javac` compiler for code editing and compilation, and > OpenJDK's debugger interface for debugging. This enables us to offer VS Code > IDE support for new JDK features as soon as they are introduced, even during > JDK Early Access phases. To this effect, this VS Code Extension will support > the current JDK releases as well as the next upcoming JDK version. For more > information, please check the announcement [6]. > ### The Java Playground > The Java Playground [7] is an online sandbox that helps testing and exploring > new Java language features. No setup required, just type your Java snippet in > your browser and run it! Right now, the Playground is using Java 21 with > Preview Features enabled, and it will switch to a new Java version as soon as > there is a new Java language features integrated in OpenJDK Early-Access > builds. The Playground is focusing mostly on Project Amber and is certainly > not mean to be some sort of a lightweight online-IDE, it is instead a > learning tool to play with new Java language feature shortly after they have > been integrated into the platform. > [1] https://inside.java/2023/09/19/the-arrival-of-java-21/ > [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html > [3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks > [4] https://www.youtube.com/watch?v=pcg-E_qyMOI > [5] https://openjdk.org/jeps/457 > [6] https://inside.java/2023/10/18/announcing-vscode-extension/ > [7] https://dev.java/playground > ## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change > As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21 > javac emits a note if _implicit_ annotation processing is being used, that > is, if one or more annotation processors are found and run from the class > path when no explicit annotation processing configuration options are used. > The note is reported since, quoting from the note text: "A future release of > javac may disable annotation processing unless at least one processor is > specified by name (-processor), or a search path is specified > (--processor-path, --processor-module-path), or annotation processing is > enabled explicitly (-proc:only, -proc:full)." > That future version of javac has
Re: Apache CXF Vulnerabilities
Hi Ashish, You don't need to wait for CXF releases to address the Guava concern if it is time critical - please include the Guava version your need into the project build definitions, that should solve the issue. For sure, upcoming CXF releases would be using the latest available version at the time of the release but there are no dates yet (tentatively, end of the year). Thank you. Best Regards, Andriy Redko > Hi Team, > In our product, we are using Apache CXF Runtime WS Security > (cxf-rt-ws-security) v3.5.5. > It having transitive dependency on Guava. Mentioned in yellow below. > Apache CXF Runtime WS Security (3.5.5) > Apache WSS4J DOM WS Security (2.4.1) > Apache WSS4J WS Security Common (2.4.1) > guava(30.1-jre) > For Guava, we have observed two vulnerabilities > (CVE-2023-2976<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2976>, > CVE-2020-8908<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8908>) > Fix of these vulnerabilities are not available on Apache CXF 3.x. > As product is on JAVA 8, hence fix will be required on Apache CXF 3.x only. > Kindly let us know by when fix will be provided on 3.x version. > Thanks > Ashish Verma
Re: Deprecate jaxws21 frontend in wsdl2java
Hi Jim, I think we should remove it for 4.x release line, looks to be a leftover from Jakarta migration, we won't be able to support it anyway I believe. Thank you. Best Regards, Andriy Redko > Hi all, > When the "-frontend jaxws21" is passed to wsdl2java tool, it doesn't work > and there is error from jaxb xjc: > . > */wsdl2java -verbose TestService.wsdlLoading FrontEnd jaxws ...Loading > DataBinding jaxb ...wsdl2java -verbose TestService.wsdlwsdl2java - Apache > CXF 4.0.4-SNAPSHOT-c429d51aa11b667a0a55d78e6f894eba246569dbCaused by: > com.sun.tools.xjc.BadCommandLineException: "2.1" is not a valid target > version. "3.0" is supported. at > com.sun.tools.xjc.Options.parseArgument(Options.java:617) at > com.sun.tools.xjc.Options.parseArguments(Options.java:853) at > org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:410)* > I looked at the wsdl2java code and it turns out the CXF created xjc > arguments "-target 2.1" for jaxws21 > frontend [1],but the jaxb runtime 3.0.2 only supports the target 2.3 and > higher version[2]. Does this means > we actually can't get jaxws21 frontend work ? > As jaxws21 is quite old , should we remove this xjc flag and make this > jaxws21 frontend > deprecated in the next release and finally remove this flag in the major > version ? > Does anyone have any concern about this change ? > [1] > https://github.com/apache/cxf/blob/main/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/JAXWS21Container.java#L44-L45 > [2] > https://github.com/eclipse-ee4j/jaxb-ri/blob/3.0.2-RI/jaxb-ri/xjc/src/main/java/com/sun/tools/xjc/api/SpecVersion.java#L19 > Thanks, > Jim
Re: CXF JAX-RS client: setting content-type for a specific method in outgoing request
Hi Jean,
The JAX-RS has full support for web forms, it should be fairly easy to do
with WebClient for example:
import javax.ws.rs.core.Form;
import javax.ws.rs.core.Response;
final WebClient client = WebClient
.create(address)
.accept("application/json")
.type("application/x-www-form-urlencoded")
.path("/");
final Form form = new Form();
form.param("token", accessToken);
try (Response response = client.post(form)) {
...
}
I hope it answers your question, thank you.
Best Regards,
Andriy Redko
> Hi Andriy,
> The 'ugly' solution I have is to pass the (url endocded) FORM data as a
> string to my interface method, which is then written to the body content.
> E.g.:
> //01.Creating a static threadsafe client proxy
> private static OidcProviderApi apiProxy;
> protected static synchronized OidcProviderApi getApiProxy() {
> if (apiProxy == null) {
> String oidcBaseAddress =
> Configuration.getInstance().getItem("oidc.introspection.uri");
> apiProxy = getThreadsafeProxy(oidcBaseAddress);
> }
> return apiProxy;
> }
> private static OidcProviderApi getThreadsafeProxy(String
> oidcBaseAddress) {
> JacksonJsonProvider provider = new JacksonJsonProvider(new
> CustomObjectMapper());
> List providers = new
> ArrayList();
> providers.add(provider);
> //Create a threadsafe proxy for the API resource
> final JAXRSClientFactoryBean factory = new
> JAXRSClientFactoryBean();
> factory.setAddress(oidcBaseAddress);
> factory.setServiceClass(OidcProviderApi.class);
> factory.setProviders(providers);
> factory.getOutInterceptors().add(new LoggingOutInterceptor());
> factory.getInInterceptors().add(new LoggingInInterceptor());
> factory.setThreadSafe(true);
> OidcProviderApi api = factory.create(OidcProviderApi.class);
> ClientConfiguration config = WebClient.getConfig(api);
> addTLSClientParameters(config.getHttpConduit());
> return api;
> }
> //02.Sending the POST request with
> 'application/x-www-form-urlencoded' body
> content containing FORM data
> //It takes the access token as input and constructs an (url encoded)
> string
> representing the FORM data having the
> // parameters: token, token_type_hint, client_assertion_type and
> client_assertion
> public Response validateAccessToken(String token) throws
> MvgBusinessFatalException {
> StringBuilder bldr = new
> StringBuilder("token=").append(token);
> bldr.append("_type_hint=access_token");
>
> bldr.append("_assertion_type=").append(URLEncoder.encode("urn:ietf:params:oauth:client-assertion-type:jwt-bearer","UTF-8"));
> String clientAssertion = ;
> bldr.append("_assertion=").append(clientAssertion);
> String urlEncodedFormData = bldr.toString();
> OidcProviderApi apiClient = getApiProxy();
> ClientConfiguration config = WebClient.getConfig(apiClient);
>
> config.getHttpConduit().getClient().setContentType("application/x-www-form-urlencoded");
> return apiClient.validateAccessToken(urlEncodedFormData);
> }
> This works, but doesn't really look nice.
> J.P.
> -Original Message-
> From: Jean Pierre URKENS
> Sent: dinsdag 19 september 2023 9:48
> To: 'Andriy Redko'
> Subject: CXF JAX-RS client: setting content-type for a specific method in
> outgoing request
> Hi Andriy,
> I've a server that expects an HTTP POST request having a body content of
> mediatype 'application/x-www-form-urlencoded' and produces a response of
> mediatype 'application/json'.
> I am using Apache CXF-v3.5.6 but I am not sure on how to create a JAXRS
> client that is able to send a POST with an
> 'application/x-www-form-urlencoded' body content.
> Are there any examples within CXF to realize this.
> Thanks for any feedback.
> Regards,
> J.P. Urkens
Re: [VOTE] CXF 4.0.3/3.6.2/3.5.7
+1, for sure, thanks Dan! Best Regards, Andriy Redko > It’s been three months since the last releases so definitely time to get more > fixes out there. > Staging areas: > https://repository.apache.org/content/repositories/orgapachecxf-1192/ > https://repository.apache.org/content/repositories/orgapachecxf-1193/ > https://repository.apache.org/content/repositories/orgapachecxf-1194/ > Tags: > https://github.com/apache/cxf/commit/4b3f0ec20cc77ff8b3c04fee44f1cb8ca525f331 > https://github.com/apache/cxf/commit/752fbd67181d7ae2bf68a632857e5c2f7c6dec6f > https://github.com/apache/cxf/commit/4adb1dc8bbd08f0910c5daef628182fea436523d > Here is my +1.
Re: Releases next week...
Hi Dan, There is only one issue still on me [1], the code is merged but I haven't completed the documentation (+ samples) yet. I will pick it up this week but please feel to close it as completed if I don't do that till the release cut. The documentation and samples could be added later on. Thank you. [1] https://issues.apache.org/jira/browse/CXF-8817 Best Regards, Andriy Redko Friday, September 8, 2023, 8:31:57 AM, you wrote: > I’ve started a vote in WebServices to release a new version of XmlSchema > which should address CXF-8924. Once that completes, I’d like to incorporate > it and do new releases of CXF. It’s been almost 3 months since the last > releases and a bunch of fixes are in. Hopefully we can get the three votes > for XmlSchema over the weekend and I can do the CXF builds early next week. > If there are any other fixes/changes needed, please get them in. > Thanks!
Re: Request mapping warnings
Hi Jean, The issue with duplicate beans registration comes from JAXRS server definition: The basePackages property triggers automatic scans which basically means that the same beans will be discovered twice. I think you could safely bring the @Service annotation back and remove basePackages property to get rid of the issue. Thanks! Best Regards, Andriy Redko JPU> No, I am not using SpringBoot in any way. JPU> Regards, JPU> J.P. JPU> *From:* Andrey Redko JPU> *Sent:* donderdag 20 juli 2023 15:24 JPU> *To:* Jean Pierre URKENS JPU> *Cc:* Daniel Kulp JPU> *Subject:* Re: Request mapping warnings JPU> Hi Jean, JPU> Do you use CXF Spring Boot autoconfiguration [1]? If yes, it has a few JPU> controls over scans [1], either beans or classes (I am off this week so JPU> cannot look into the configuration). Thank you. JPU> [1] https://cxf.apache.org/docs/springboot.html JPU> Best Regards, JPU> Andriy Redko JPU> On Thu, Jul 20, 2023, 2:23 AM Jean Pierre URKENS < JPU> jean-pierre.urk...@devoteam.com> wrote: JPU> Hi all, JPU> As a test I removed the @org.springframework.stereotype.Service(“ JPU> *KmopDienstverlenerApi*”) annotation on my service implementation class. So JPU> no @Service annotations further exist. Still when checking the return of JPU> *JAXRSUtils.**getRootResources*(Message message) via breakpoint I JPU> Still notice that my service classes are listed twice in the return result JPU> *List*. JPU> The only annotations I’ve left in my code are: JPU>- standard JAX-RS annotations: JPU> javax.ws.rs.[GET|POST|Consumes|Produces|HeaderParam|PathParam|QueryParam|Path|core.MediaType|core.Response] JPU>- io.swagger.v3.oas.annotations.* JPU> I suppose none of these would be responsible for an extra registration of JPU> my service classes. JPU> So the only point where service registration occurs is in the bean JPU> declaration file cxf-endpoint.xml, see attachment. The only thing I can JPU> think of a possible double registration in this file is the declaration of JPU> the OpenApiFeature (e.g. ) for each JPU> resource endpoint in addition to the declaration using JPU> this OpenApiFeature. JPU> But I would assume that configuring the OpenApiFeature, through a bean JPU> declaration, wouldn’t register a service. JPU> The ‘imported’ resources context-v2.xml and onderneming-context.xml define JPU> some instances that have nothing to do with these JAX-WS/RS JPU> endpoints declared in this file. JPU> Is there something I can trace into to see when a service gets registered JPU> as a *ClassResourceInfo *? JPU> Regards, JPU> J.P. Urkens JPU> *From:* Andrey Redko JPU> *Sent:* woensdag 19 juli 2023 19:30 JPU> *To:* Jean Pierre URKENS JPU> *Cc:* Daniel Kulp JPU> *Subject:* Re: Request mapping warnings JPU> Hi Jean, JPU> Indeed it looks like you have the same resource registered twice hence the JPU> warning. It may come from the use of automatic resource scans and manual JPU> resource registration. JPU> Best Regards, JPU> Andriy Redko JPU> On Wed, Jul 19, 2023, 7:39 AM Jean Pierre URKENS < JPU> jean-pierre.urk...@devoteam.com> wrote: JPU> Still some minor issue related to request mapping. JPU> I notice I am getting warnings like: JPU> *2023-07-19 13:08:23,022 [T8N1TP1-4] WARN JPU> (SID=8806F673DEC6B53D9248AF0DD81F6882) JPU> (org.apache.cxf.jaxrs.model.OperationResourceInfoComparatorBase:102) - Both JPU> be.dvtm.aeo.op.openapi.api.impl.KmopDienstverlenerApiServiceImpl#getDvlById JPU> and JPU> be.dvtm.aeo.op.openapi.api.impl.KmopDienstverlenerApiServiceImpl#getDvlById JPU> are equal candidates for handling the current request which can lead to JPU> unpredictable results* JPU> Obvious that they are equal candidates because they are the same class. But JPU> what is the cause of this double detection? JPU> Is it because when *JAXRSUtils.**getRootResources*(Message message) gets JPU> called, I see that it contains 4 entries: JPU> · (twice) KmopDienstverlenerApiServiceImpl -> my service endpoint JPU> · io.swagger.v3.jaxrs2.integration.resources.OpenApiResource JPU> · org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService JPU> So twice my service implementation, I wouldn’t know why this is the case? JPU> On my classpath I have set: JPU> · cxf-rt-rs-service-description-3.5.6.jar -> this JPU> handles request for ‘_wadl’ JPU> · cxf-rt-rs-service-description-openapi-v3-3.5.6.jar -> this JPU> handles request for ‘openapi.[yaml|json]’ JPU> · cxf-rt-rs-service-description-swagger-ui-3.5.6.jar -> this JPU> handles request for ‘Swagger documentation’ JPU> would this be a cause for my servic
Re: How to setup multiple JAXRS server endpoints
Got it, thank you (the Swagger sometimes does surprising things).
Thursday, July 13, 2023, 1:33:07 AM, you wrote:
JPU> The @Parameter annotation seems to be ignored at this level.
JPU> -Original Message-
JPU> From: Jean Pierre URKENS
JPU> Sent: donderdag 13 juli 2023 7:11
JPU> To: 'Andriy Redko' ; 'dev@cxf.apache.org'
JPU>
JPU> Subject: RE: How to setup multiple JAXRS server endpoints
JPU> Yes, SwaggerUI works too!
JPU> I noticed that v2.x of swagger-jaxrs relates to OpenApi v3.1.x while my
spec
JPU> is compliant with OpenApi v3.0.x, so I am going to stick with v2.1.13 which
JPU> seems to be that last version for OpenApi v3.0.x.
JPU> I thought the @Parameter only applied to input parameters ("query",
JPU> "header", "path" or "cookie" parameters), but I'll give it a try.
JPU> J.P.
JPU> -Original Message-
JPU> From: Andriy Redko
JPU> Sent: woensdag 12 juli 2023 22:16
JPU> To: Jean Pierre URKENS ;
dev@cxf.apache.org
JPU> Subject: Re: How to setup multiple JAXRS server endpoints
JPU> Hi Jean,
JPU> That's awesome, have you got SwaggerUI working as well?
JPU> Yes, you could use 2.2.15 (we already updated to this version, no
JPU> regressions). It seems like the description applies to the whole schema
JPU> (which is the same for both properties), may be you could use @Parameter
JPU> instead:
JPU> @Parameter(description="The description I want for prop1")
JPU> Thank you.
JPU> Best Regards,
JPU> Andriy Redko
>> Hi Andriy,
>> After having migrated everything to "io.swagger.v3.oas.annotations.*" the
>> swagger endpoints for each of my services became active.
>> So far so good, but I do notice that there are discrepancies when
>> annotating models, e.g.:
>> public class Model1 {
>> @Schema(description="The description I want for prop1")
>>private Model2 prop1;
>> @Schema(description="The description I want for prop2")
>>private Model2 prop2;
>> ...
>> }
>> When I generate the openapi.[json|yaml] specification I see that both
>> prop1 and prop2 have a reference to the schema component "Model2" with
>> description ' The description I want for prop2' which is inappropriate for
>> 'prop1'.
>> It is not unlikely to have multiple properties within one Model that are
>> of the same class but are semantically used in a different context. E.g.
>> something as simple as a ShipmentOrder having two 'Address' properties
>> 'from' and 'to' would result in wrong API documentation.
>> I am aware it has nothing to do with CXF but rather with
>> swagger-jaxrs2-vx.y.z.jar and depending libraries. CXF-3.5.6 has
>> dependency on swagger-jaxrs2-2.1.13.jar. Would it be an issue to replace
>> this dependency with e.g. swagger-jaxrs2-2.2.15.jar (latest stable release
>> according to maven central repo)?
>> J.P.
>> -Original Message-
>> From: Jean Pierre URKENS
>> Sent: woensdag 12 juli 2023 8:25
>> To: 'Andriy Redko' ; 'dev@cxf.apache.org'
>>
>> Subject: RE: How to setup multiple JAXRS server endpoints I seem to be
>> mistaken here, the endpoint was loaded (I did a manual HTTP GET test to
>> the endpoint to verify this) although no breakpoints where hit during
>> startup.
>> I am first going to complete the migration to
>> "io.swagger.v3.oas.annotations.*" annotations for all endpoints and then I
>> am going to test again.
>> The application is composed of libraries, some of which use SLF4J but most
>> use LOG4J for logging.
>> J.P.
>> -Original Message-
>> From: Andriy Redko
>> Sent: woensdag 12 juli 2023 1:13
>> To: Jean Pierre URKENS ;
>> dev@cxf.apache.org
>> Subject: Re: How to setup multiple JAXRS server endpoints Hi Jean, The
>> OpenApiFeature$Portable#initiliaze(…) should definitely be called
>> (otherwise you shouldn't even see the openapi.json endpoint), so I am not
>> sure why these are not triggering for you.
>>
>> For logging, it seems like you are using SLF4J
>> (org.apache.cxf.common.logging.Slf4jLogger),
>> and also reload4j (aka log4j), why do you need both?
>> Thank you.
>> Best Regards,
>> Andriy Redko
JPU>>> After some code investigation:
JPU>>> OpenApiFeature implements SwaggerUiSupport and in its
JPU>>> portable#registerSwaggerUiResources(…) method it will call
JPU>>> SwaggerUiSupport#getSwaggerUi(…) which will register the
JPU> SwaggerUiService.
JPU>>> I have put breakpoints on:
JPU>>>- OpenApiFeature$Portable#initiliaze(…)
JPU>>>- SwaggerUiSe
Re: How to setup multiple JAXRS server endpoints
Hi Jean,
That's awesome, have you got SwaggerUI working as well?
Yes, you could use 2.2.15 (we already updated to this version, no regressions).
It seems like the
description applies to the whole schema (which is the same for both
properties), may be you could
use @Parameter instead:
@Parameter(description="The description I want for prop1")
Thank you.
Best Regards,
Andriy Redko
> Hi Andriy,
> After having migrated everything to "io.swagger.v3.oas.annotations.*" the
> swagger endpoints for each of my services became active.
> So far so good, but I do notice that there are discrepancies when annotating
> models, e.g.:
> public class Model1 {
> @Schema(description="The description I want for prop1")
>private Model2 prop1;
> @Schema(description="The description I want for prop2")
>private Model2 prop2;
> ...
> }
> When I generate the openapi.[json|yaml] specification I see that both prop1
> and prop2 have a reference to the schema component "Model2" with description
> ' The description I want for prop2' which is inappropriate for 'prop1'.
> It is not unlikely to have multiple properties within one Model that are of
> the same class but are semantically used in a different context. E.g.
> something as simple as a ShipmentOrder having two 'Address' properties 'from'
> and 'to' would result in wrong API documentation.
> I am aware it has nothing to do with CXF but rather with
> swagger-jaxrs2-vx.y.z.jar and depending libraries. CXF-3.5.6 has dependency
> on swagger-jaxrs2-2.1.13.jar. Would it be an issue to replace this dependency
> with e.g. swagger-jaxrs2-2.2.15.jar (latest stable release according to maven
> central repo)?
> J.P.
> -Original Message-
> From: Jean Pierre URKENS
> Sent: woensdag 12 juli 2023 8:25
> To: 'Andriy Redko' ; 'dev@cxf.apache.org'
>
> Subject: RE: How to setup multiple JAXRS server endpoints
> I seem to be mistaken here, the endpoint was loaded (I did a manual HTTP GET
> test to the endpoint to verify this) although no breakpoints where hit during
> startup.
> I am first going to complete the migration to
> "io.swagger.v3.oas.annotations.*" annotations for all endpoints and then I am
> going to test again.
> The application is composed of libraries, some of which use SLF4J but most
> use LOG4J for logging.
> J.P.
> -Original Message-
> From: Andriy Redko
> Sent: woensdag 12 juli 2023 1:13
> To: Jean Pierre URKENS ; dev@cxf.apache.org
> Subject: Re: How to setup multiple JAXRS server endpoints
> Hi Jean,
> The OpenApiFeature$Portable#initiliaze(…) should definitely be called
> (otherwise you shouldn't even see the openapi.json endpoint), so I am not
> sure why these are not triggering for you.
>
> For logging, it seems like you are using SLF4J
> (org.apache.cxf.common.logging.Slf4jLogger),
> and also reload4j (aka log4j), why do you need both?
> Thank you.
> Best Regards,
> Andriy Redko
JPU>> After some code investigation:
JPU>> OpenApiFeature implements SwaggerUiSupport and in its
JPU>> portable#registerSwaggerUiResources(…) method it will call
JPU>> SwaggerUiSupport#getSwaggerUi(…) which will register the
SwaggerUiService.
JPU>> I have put breakpoints on:
JPU>>- OpenApiFeature$Portable#initiliaze(…)
JPU>>- SwaggerUiService constructor
JPU>>- SwaggerUiSupport#getSwaggerUi(…)
JPU>> but none of them are hit when starting my application?
JPU>> Although the (spring) logging shows all beans in my
JPU>> cxf-endpoints.xml have been created?
JPU>> The *WADL* and *OpenAPI* endpoints to get the specification work.
JPU>> Even the actual endpoint seems to work although I didn’t hit any of
JPU>> the breakpoint?
JPU>> CXF, also doesn’t seem to log a lot, I am hardly getting any log
JPU>> entries although log level I set to DEBUG.
JPU>> My logging (except wire message logging) for cxf is setup correctly
JPU>> (I
JPU>> think):
JPU>>- ../META-INF/cxf/org.apache.cxf.Logger contains the line
JPU>>‘org.apache.cxf.common.logging.Slf4jLogger’
JPU>>- slf4j-api-1.7.36.jar, slf4j-reload4j-1.7.36.jar and
JPU>>reload4j-1.2.19.jar are on the classpath
JPU>>- the log4j.properties file contains the line:
JPU>>‘log4j.logger.org.apache.cxf=DEBUG’
JPU>> There are no special instructions mentioned on
JPU>> https://cxf.apache.org/docs/general-cxf-logging.html so the above
JPU>> should work (it works for all other packages I use in my application).
JPU>> J.P.
JPU>> *From:* Jean Pierre URKENS
JPU>> *Sent:* dinsdag 11 juli 2023 9:58
JPU>> *To:* 'Andriy Redko' ; 'dev@cxf
Re: How to setup multiple JAXRS server endpoints
Hi Jean, The OpenApiFeature$Portable#initiliaze(…) should definitely be called (otherwise you shouldn't even see the openapi.json endpoint), so I am not sure why these are not triggering for you. For logging, it seems like you are using SLF4J (org.apache.cxf.common.logging.Slf4jLogger), and also reload4j (aka log4j), why do you need both? Thank you. Best Regards, Andriy Redko JPU> After some code investigation: JPU> OpenApiFeature implements SwaggerUiSupport and in its JPU> portable#registerSwaggerUiResources(…) method it will call JPU> SwaggerUiSupport#getSwaggerUi(…) which will register the SwaggerUiService. JPU> I have put breakpoints on: JPU>- OpenApiFeature$Portable#initiliaze(…) JPU>- SwaggerUiService constructor JPU>- SwaggerUiSupport#getSwaggerUi(…) JPU> but none of them are hit when starting my application? JPU> Although the (spring) logging shows all beans in my cxf-endpoints.xml have JPU> been created? JPU> The *WADL* and *OpenAPI* endpoints to get the specification work. JPU> Even the actual endpoint seems to work although I didn’t hit any of the JPU> breakpoint? JPU> CXF, also doesn’t seem to log a lot, I am hardly getting any log entries JPU> although log level I set to DEBUG. JPU> My logging (except wire message logging) for cxf is setup correctly (I JPU> think): JPU>- ../META-INF/cxf/org.apache.cxf.Logger contains the line JPU>‘org.apache.cxf.common.logging.Slf4jLogger’ JPU>- slf4j-api-1.7.36.jar, slf4j-reload4j-1.7.36.jar and JPU>reload4j-1.2.19.jar are on the classpath JPU>- the log4j.properties file contains the line: JPU>‘log4j.logger.org.apache.cxf=DEBUG’ JPU> There are no special instructions mentioned on JPU> https://cxf.apache.org/docs/general-cxf-logging.html so the above should JPU> work (it works for all other packages I use in my application). JPU> J.P. JPU> *From:* Jean Pierre URKENS JPU> *Sent:* dinsdag 11 juli 2023 9:58 JPU> *To:* 'Andriy Redko' ; 'dev@cxf.apache.org' < dev@cxf.apache.org>> JPU> *Subject:* RE: How to setup multiple JAXRS server endpoints JPU> Hi Andriy, JPU> As a test I removed all JAX-RS endpoints that use Swagger v2 annotations JPU> from my configuration file (see attachment). JPU> So I've now only 1 JAX-RS endpoint, fully annotated with Swagger v3 JPU> annotations, using the OpenApiFeature i.o. Swagger2Feature. JPU> If I run my server with this configuration I only get the (working) *WADL* JPU> and *OpenAPI* endpoints, no Swagger UI endpoint: JPU> So there is some configuration missing to detect/activate the Swagger JPU> endpoint. When I look at the samples that come with the distribution of CXF JPU> (I am using v3.5.6) nothing special seems to be configured to activate this? JPU> Do you have any idea how the SwaggerUiService is picked up when loading? JPU> J.P. JPU> -Original Message- JPU> From: Andriy Redko JPU> Sent: dinsdag 11 juli 2023 3:44 JPU> To: Jean Pierre URKENS ; dev@cxf.apache.org JPU> Subject: Re: How to setup multiple JAXRS server endpoints JPU> Hi Jean, JPU> I guess you figured one issue, swagger.json -> openapi.json, but to be JPU> honest we have never tested or envisioned the application that would use JPU> OpenAPI 2.0 (Swagger) and OpenAPI 3.0 at the same time, I am afraid this is JPU> just not supported. You may get things back on track when going with JPU> OpenAPI 3.0 for all services. JPU> Thank you. JPU> Best Regards, JPU> Andriy Redko >> Hi Andriy, >> I am trying to trace the difference in handling with another >> application where I’ve got only one CXF service endpoint that uses >> swagger v3 openapi annotations. >> There I see that when handling the Swagger page request ( >> http://l-p53-008:8082/idb-fe/services/api-docs?url=openapi.json) the >> JAXRSInInterceptor is calling: >> *JAXRSUtils.**getRootResources*(Message message) >> It contains 4 entries: >>- (twice) InkomOndernemingApiserviceImpl -> my service endpoint >>- io.swagger.v3.jaxrs2.integration.resources.OpenApiResource >>- org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService >> On the application described below with the service ‘oidcsim’ when >> calling the swagger page request >> (l-p53-008:8081/op/services/oidcsim/api-docs?url=openapi.json) the >> result of the getRootResources doesn’t contain the ClassResourceInfo ‘ >> SwaggerUiService’. It only contains 3 entries: >>- (twice) OidcProviderApiServiceImpl (my service endpoint) >>- io.swagger.v3.jaxrs2.integration.resources.OpenApiResource >> The SwaggerUiService is the one that is configured to han
Re: How to setup multiple JAXRS server endpoints
Hi Jean, Everything looks as it should be so far, may I ask you please to (re)confirm that you have SwaggerUI dependency included (fe 5.1.0 but any of 4.x should also work): org.webjars swagger-ui 5.1.0 Thank you. Best Regards, Andriy Redko JPU> Hi Andriy, JPU> As a test I removed all JAX-RS endpoints that use Swagger v2 annotations JPU> from my configuration file (see attachment). JPU> So I've now only 1 JAX-RS endpoint, fully annotated with Swagger v3 JPU> annotations, using the OpenApiFeature i.o. Swagger2Feature. JPU> If I run my server with this configuration I only get the (working) *WADL* JPU> and *OpenAPI* endpoints, no Swagger UI endpoint: JPU> So there is some configuration missing to detect/activate the Swagger JPU> endpoint. When I look at the samples that come with the distribution of CXF JPU> (I am using v3.5.6) nothing special seems to be configured to activate this? JPU> Do you have any idea how the SwaggerUiService is picked up when loading? JPU> J.P. JPU> -Original Message- JPU> From: Andriy Redko JPU> Sent: dinsdag 11 juli 2023 3:44 JPU> To: Jean Pierre URKENS ; dev@cxf.apache.org JPU> Subject: Re: How to setup multiple JAXRS server endpoints JPU> Hi Jean, JPU> I guess you figured one issue, swagger.json -> openapi.json, but to be JPU> honest we have never tested or envisioned the application that would use JPU> OpenAPI 2.0 (Swagger) and OpenAPI 3.0 at the same time, I am afraid this is JPU> just not supported. You may get things back on track when going with JPU> OpenAPI 3.0 for all services. JPU> Thank you. JPU> Best Regards, JPU> Andriy Redko >> Hi Andriy, >> I am trying to trace the difference in handling with another >> application where I’ve got only one CXF service endpoint that uses >> swagger v3 openapi annotations. >> There I see that when handling the Swagger page request ( >> http://l-p53-008:8082/idb-fe/services/api-docs?url=openapi.json) the >> JAXRSInInterceptor is calling: >> *JAXRSUtils.**getRootResources*(Message message) >> It contains 4 entries: >>- (twice) InkomOndernemingApiserviceImpl -> my service endpoint >>- io.swagger.v3.jaxrs2.integration.resources.OpenApiResource >>- org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService >> On the application described below with the service ‘oidcsim’ when >> calling the swagger page request >> (l-p53-008:8081/op/services/oidcsim/api-docs?url=openapi.json) the >> result of the getRootResources doesn’t contain the ClassResourceInfo ‘ >> SwaggerUiService’. It only contains 3 entries: >>- (twice) OidcProviderApiServiceImpl (my service endpoint) >>- io.swagger.v3.jaxrs2.integration.resources.OpenApiResource >> The SwaggerUiService is the one that is configured to handle the JPU> ‘api-docs’ >> path-request. Since it is missing the request is tried to match with >> the other two resources but fails, hence ‘NOT FOUND’ exception. >> I can’t trace back where these rootResources are set and why the >> SwaggerUiService’ isn’t listed. >> J.P. >> *From:* Jean Pierre URKENS >> *Sent:* maandag 10 juli 2023 13:43 >> *To:* 'Andriy Redko' >> *Subject:* RE: How to setup multiple JAXRS server endpoints >> Andriy, >> I am trying to switch from Swagger v2 to OpenApi v3 annotations >> basically because my starting point is an OpenApi v3.0.7 yaml file >> description and OpenAPI seems to be the way forward. >> For applications where I have only one CXF JAX-RS endpoint exposed I >> had no problems converting. However as soon as there are multiple >> endpoints I run into troubles. >> So, to recall, I've an application exposing 3 JAX-RS endpoints that >> where previously annotated with swagger v2 annotations (i.e. package >> io.swagger.annotations.*) which I migrated to >> swagger v3 annotations (package io.swagger.v3.oas.annotations.*). In >> accordance I altered my CXF JAX-RS endpoint configuration from (only >> showing relevant parts, see attachment for full setup): >> >>> class="org.apache.cxf.jaxrs.swagger.ui.SwaggerUiConfig"> >> > > value="/op/services/oidcsim/swagger.yaml"/> >> >>> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature"> >> > value="/op/services/oidcsim"/> >>
Re: How to setup multiple JAXRS server endpoints
Hi Jean,
I guess you figured one issue, swagger.json -> openapi.json, but to be honest
we have never
tested or envisioned the application that would use OpenAPI 2.0 (Swagger) and
OpenAPI 3.0 at
the same time, I am afraid this is just not supported. You may get things back
on track when
going with OpenAPI 3.0 for all services.
Thank you.
Best Regards,
Andriy Redko
> Hi Andriy,
> I am trying to trace the difference in handling with another application
> where I’ve got only one CXF service endpoint that uses swagger v3 openapi
> annotations.
> There I see that when handling the Swagger page request (
> http://l-p53-008:8082/idb-fe/services/api-docs?url=openapi.json) the
> JAXRSInInterceptor is calling:
> *JAXRSUtils.**getRootResources*(Message message)
> It contains 4 entries:
> - (twice) InkomOndernemingApiserviceImpl -> my service endpoint
> - io.swagger.v3.jaxrs2.integration.resources.OpenApiResource
> - org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService
> On the application described below with the service ‘oidcsim’ when calling
> the swagger page request
> (l-p53-008:8081/op/services/oidcsim/api-docs?url=openapi.json) the result
> of the getRootResources doesn’t contain the ClassResourceInfo ‘
> SwaggerUiService’. It only contains 3 entries:
> - (twice) OidcProviderApiServiceImpl (my service endpoint)
> - io.swagger.v3.jaxrs2.integration.resources.OpenApiResource
> The SwaggerUiService is the one that is configured to handle the ‘api-docs’
> path-request. Since it is missing the request is tried to match with the
> other two resources but fails, hence ‘NOT FOUND’ exception.
> I can’t trace back where these rootResources are set and why the
> SwaggerUiService’ isn’t listed.
> J.P.
> *From:* Jean Pierre URKENS
> *Sent:* maandag 10 juli 2023 13:43
> *To:* 'Andriy Redko'
> *Subject:* RE: How to setup multiple JAXRS server endpoints
> Andriy,
> I am trying to switch from Swagger v2 to OpenApi v3 annotations basically
> because my starting point is an OpenApi v3.0.7 yaml file description and
> OpenAPI seems to be the way forward.
> For applications where I have only one CXF JAX-RS endpoint exposed I had no
> problems converting. However as soon as there are multiple endpoints I run
> into troubles.
> So, to recall, I've an application exposing 3 JAX-RS endpoints that where
> previously annotated with swagger v2 annotations (i.e. package
> io.swagger.annotations.*) which I migrated to
> swagger v3 annotations (package io.swagger.v3.oas.annotations.*). In
> accordance I altered my CXF JAX-RS endpoint configuration from (only
> showing relevant parts, see attachment for full setup):
>
> class="org.apache.cxf.jaxrs.swagger.ui.SwaggerUiConfig">
> value="/op/services/oidcsim/swagger.yaml"/>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> value="/op/services/oidcsim"/>
> value="be.dvtm.aeo.op.oidc"/>
> ref="SwaggerUiConfigOidcApi"/>
>
> basePackages="be.dvtm.aeo.op.oidc" address="/oidcsim">
>
>
> bean="Swagger2FeatureOidcApi" />
>
> ...
>
> TO:
>
> class="org.apache.cxf.jaxrs.swagger.ui.SwaggerUiConfig">
>
>
> class="org.apache.cxf.jaxrs.openapi.OpenApiFeature">
> ref="OidcSwaggerUiConfig"/>
>
> value="be.dvtm.aeo.op.oidc"/>
>
> basePackages="be.dvtm.aeo.op.oidc" address="/oidcsim">
>
>
>
> ...
>
> Now when starting my application and navigating to the root part "
> http://localhost:localPort/op/services" I get an overview of all my
> endpoints:
[PROPOSAL] Branch of 4.0.x, move main to 4.1.x (Jakarta EE 10)
Hey Folks, The work on Jakarta EE 10 had started already (so far the progress was a bit slower than desired but the things should accelerate I hope). It becomes increasingly difficult to keep the separate pull request [1] intact (particularly, dependabot is constantly trying to update to latest specs). To ease the implementation efforts, I would like to propose to: - branch of 4.0.x-fixes from main - move main to 4.1.x - work on [1] to be ready for merge with main From the maintenance perspective, that would increase a bit the amount of work required: - 3.5.x and 3.6.x: those are the last (hopefully) branches for javax.* to maintain - 4.0.x and 4.1.x (upcoming): those are the ones to support going forward for jakarta.* to maintain Any feedback / thoughts / suggestions are very welcome! Thanks! [1] https://issues.apache.org/jira/browse/CXF-8671 [2] https://github.com/apache/cxf/pull/1201 Best Regards, Andriy Redko
Re: Apache CXF JAX-RS threadsafe clients
Hi Jean,
AFAIK, conceptually, the headers and query parameters are handled the "same"
way by the
underlying client (from state perspective). Since you already have a test, it
would be great
to add header verification, you have everything in place already for that,
should be pretty
straightforward. I don't expect surprises here but it won't hurt I believe.
Thanks.
Best Regards,
Andriy Redko
Tuesday, July 4, 2023, 4:47:59 AM, you wrote:
> Hi Andriy,
> I wrote a multi-threaded test based on
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSMultithreadedClientTest.java.
> It creates 9 threads each executing 9 API requests. The test execution looks
> like (step 5 and 6 are executed multi-threaded):
> 1.Create server endpoint
> 2.Create threadsafe API client
> 3.Create 9 credentials (credential is a person having the right to
> access a
> 'specified' company)
> 4.Obtain accessTokens for each credential from the server endpoint
> (so also
> 9 accessTokens are available)
> 5.Create 9 threads (one for each credential)
> 6.Within each thread validate each of the 9 accessTokens for the
> passed-on
> credential by sending a validateAccesstoken request to the server. So 8 will
> say 'NOT OK', one will say 'OK'.
> All communication with the server endpoint is done through the singleton
> instance of the threadsafe API client.
> All 9 threads with in total 9*9=81 API requests complete as expected.
> The test isn't similar to the JAXRSMultithreadedClientTest test, in the
> sense that it doesn't verify the round-trip modification of HTTP headers by
> each API invocation. I.e. this specific client (in the
> meantime I have 5 different JAXRS clients developed, one for each supporting
> interface) doesn't set specific HTTP headers, only query parameters for each
> API invocation.
> Do you think it would be needed to verify whether headers are passed
> correctly for each API invocation?
> Regards,
> J.P.
> -Original Message-
> From: Andriy Redko
> Sent: vrijdag 30 juni 2023 3:59
> To: Jean Pierre URKENS ; CXF Dev List
>
> Subject: Re: Apache CXF JAX-RS threadsafe clients
> Hi Jean,
> Yes, I believe that call to:
> SodexoApi clientProxy =
> JAXRSClientFactory.fromClient(WebClient.client(getClientProxy()),
> SodexoApi.class);
> is not needed (since as you rightly pointed out, SodexoApi is already thread
> safe proxy). Folks, correct us here if that is not the case.
> Thank you.
> Best Regards,
> Andriy Redko
>> Hi Andriy,
>> Ok, it is clear for the 1st part, which I restructured to:
>> private static SodexoApi getThreadsafeProxy(String
>> baseAddress) throws GeneralSecurityException {
>> JacksonJsonProvider provider = new
>> JacksonJsonProvider(new CustomObjectMapper());
>> List providers = new
>> ArrayList();
>> providers.add(provider);
>> final JAXRSClientFactoryBean factory = new
>> JAXRSClientFactoryBean();
>> factory.setAddress(baseAddress);
>> factory.setServiceClass(SodexoApi.class);
>> factory.setProviders(providers);
>> factory.getOutInterceptors().add(new
>> LoggingOutInterceptor());
>> factory.getInInterceptors().add(new
>> LoggingInInterceptor());
>> factory.setThreadSafe(true);
>> SodexoApi api = factory.create(SodexoApi.class);
>> ClientConfiguration config = WebClient.getConfig(api);
>> addTLSClientParameters(config.getHttpConduit());
>> return api;
>> }
>> You’re less clear on the 2nd part. If I look at the example
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSMultithreadedClientTest.java
>> (especially the runproxies() method), then in my service method (which I
>> am trying to make threadsafe) I wouldn’t need to call:
>> //Get a threadsafe API client
>> SodexoApi clientProxy =
>> JAXRSClientFactory.fromClient(WebClient.client(getClientProxy()),
>> SodexoApi.class); The getClientProxy() which returns a singleton instance
>> from the getThreadsafeProxy(…) method above is already threadsafe even
>> though it is the same proxy instance for all service invocations as state
>> is kept in a ThreadLocalClientState object.
>> So my service method could just look like (still need a casting to
>> WebClient to be able to set the authorization HTTP header):
>&g
Re: Apache CXF JAX-RS threadsafe clients
Hi Jean,
Yes, I believe that call to:
SodexoApi clientProxy =
JAXRSClientFactory.fromClient(WebClient.client(getClientProxy()),
SodexoApi.class);
is not needed (since as you rightly pointed out, SodexoApi is already thread
safe proxy). Folks, correct us
here if that is not the case.
Thank you.
Best Regards,
Andriy Redko
> Hi Andriy,
> Ok, it is clear for the 1st part, which I restructured to:
> private static SodexoApi getThreadsafeProxy(String baseAddress)
> throws GeneralSecurityException {
> JacksonJsonProvider provider = new JacksonJsonProvider(new
> CustomObjectMapper());
> List providers = new
> ArrayList();
> providers.add(provider);
>
> final JAXRSClientFactoryBean factory = new
> JAXRSClientFactoryBean();
> factory.setAddress(baseAddress);
> factory.setServiceClass(SodexoApi.class);
> factory.setProviders(providers);
> factory.getOutInterceptors().add(new LoggingOutInterceptor());
> factory.getInInterceptors().add(new LoggingInInterceptor());
> factory.setThreadSafe(true);
> SodexoApi api = factory.create(SodexoApi.class);
> ClientConfiguration config = WebClient.getConfig(api);
> addTLSClientParameters(config.getHttpConduit());
> return api;
> }
> You’re less clear on the 2nd part. If I look at the example
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSMultithreadedClientTest.java
> (especially the runproxies() method),
> then in my service method (which I am trying to make threadsafe) I wouldn’t
> need to call:
> //Get a threadsafe API client
> SodexoApi clientProxy =
> JAXRSClientFactory.fromClient(WebClient.client(getClientProxy()),
> SodexoApi.class);
> The getClientProxy() which returns a singleton instance from the
> getThreadsafeProxy(…) method above is already threadsafe even though it is
> the same proxy instance for all service invocations as state is kept in a
> ThreadLocalClientState object.
> So my service method could just look like (still need a casting to WebClient
> to be able to set the authorization HTTP header):
> public synchronized Response closeAccount(UUID operationId, Long
> authorisationId, AccountKey accountKey) {
> try {
> //Set the Bearer authorization header
> String issuer =
> Configuration.getInstance().getItem(EmittentProperties.emit_security_bearer_issuer);
> String audience =
> Configuration.getInstance().getItem(EmittentProperties.emit_security_bearer_audience);
> String jws =
> BearerUtils.createJwtSignedJose(BearerUtils.SDX_HEADER_TYPE,issuer,audience,
> operationId.toString(),(PrivateKey)
> BearerUtils.getKey(KeyName.kmopSignPrivKey));
> WebClient.client(getClientProxy())
> .reset()
> .header(HttpHeaders.AUTHORIZATION,
> "Bearer " + jws);
> //Send service request
> return
> getClientProxy().closeAccount(operationId.toString(), authorisationId,
> accountKey);
> } catch (GeneralSecurityException e) {
> StringBuilder bldr = new StringBuilder("Internal
> error processing customerFund request (")
>
> .append("operationId=").append(operationId.toString())
>
> .append(",authorisationId=").append(authorisationId)
> .append("): ").append(e.getMessage());
> LOG.error(bldr.toString(), e);
> return
> Response.status(Status.INTERNAL_SERVER_ERROR).entity(e.getMessage()).build();
> }
> }
> Regards,
> J.P.
> -Original Message-
> From: Andriy Redko
> Sent: woensdag 28 juni 2023 23:55
> To: Jean Pierre URKENS ; CXF Dev List
>
> Subject: Re: Apache CXF JAX-RS threadsafe clients
> Hi Jean,
> So the 1st part is 100% correct way to create a thread safe client proxy, but
> with the 2nd one we have an issue well documented here [1]. Since you only
> modify headers, the thread safe proxy should work, but you probably could
> avoid using the WebClient part (just use JAXRSClientFactoryBean)
> directly:
> final JAXRSClientFactoryBean factory = new JAXRSClientFactoryBea
Re: Apache CXF JAX-RS threadsafe clients
Hi Jean,
So the 1st part is 100% correct way to create a thread safe client proxy, but
with the 2nd one
we have an issue well documented here [1]. Since you only modify headers, the
thread safe proxy
should work, but you probably could avoid using the WebClient part (just use
JAXRSClientFactoryBean)
directly:
final JAXRSClientFactoryBean factory = new JAXRSClientFactoryBean();
factory.setServiceClass(SodexoApi.class);
factory.setProviders(providers);
factory.getOutInterceptors().add(new LoggingOutInterceptor());
factory.getInInterceptors().add(new LoggingInInterceptor());
factory.setThreadSafe(true)
SodexoApi api = factory.create(SodexoApi.class);
ClientConfiguration config = WebClient.getConfig(api);
addTLSClientParameters(config.getHttpConduit());
Hope it helps!
[1]
https://cxf.apache.org/docs/jax-rs-client-api.html#JAXRSClientAPI-ThreadSafety
Best Regards,
Andriy Redko
JPU> Apache CXF JAX-RS threadsafe clients
JPU> Hi Andriy,
JPU> I am struggling to understand threadsafety when creating/using JAX-RS
JPU> clients.
JPU> My intention is to:
JPU> 1. Create a client once as I think it is heavy loaded:
JPU> o We need to add providers and interceptors
JPU> o We need to set TLS-client parameters
JPU> 2. Then (re-)use this client in a threadsafe way for multiple
JPU> (possibly concurrent) invocations of service methods
JPU> So step ‘1.’ I have done by creating a static threadsafe proxy using the
JPU> JAXRSClientFactory class.
JPU> Now the problem is step ‘2.’ How do I invoke this (static) client to make
JPU> sure that:
JPU> · Stuff under’1.’ is reused
JPU> · Reset and add headers specific for this invocation
JPU> · all is threadsafe
JPU> Currently, in my service method I create a client as follows:
JPU> SodexoApi* clientProxy* =
JAXRSClientFactory.*fromClient*(WebClient.*client*
JPU> (*getClientProxy*()), SodexoApi.*class*);
JPU> Here getClientProxy() is the static proxy I created, covering for step ‘1.’
JPU> Stuff, that I want to re-use to create a proxy for the SodexoApi interface.
JPU> But I am doubting whether this is the correct way.
JPU> For the moment I don’t think I’ve a problem due to the fact that the
JPU> service methods are defined as ‘synchronized’ but that comes with a
JPU> performance penalty.
JPU> Below, a stripped version of the code I am using, to help you understanding
JPU> what I am trying to do:
JPU> public class SodexoApiClientImpl {
JPU> private static final Logger LOG =
JPU> Logger.getLogger(SodexoApiClientImpl.class);
JPU> /** custom HEADER field name for X-KMO-OPERATION-ID */
JPU> public static final String HEADER_OPERATION_ID =
JPU> "X-KMO-OPERATION-ID";
JPU> /** A threadsafe proxy to serve as {@link WebClient} for the {@link
JPU> SodexoApi} interface*/
JPU> private static SodexoApi clientProxy;
JPU> protected static synchronized SodexoApi getClientProxy() throws
JPU> GeneralSecurityException {
JPU> if (clientProxy == null) {
JPU> //Get the base address of the service endpoint
JPU> String baseAddress =
JPU>
Configuration.getInstance().getItem(EmittentProperties.emmitent_service_endpoint);
JPU> clientProxy = getThreadsafeProxy(baseAddress);
JPU> }
JPU> return clientProxy;
JPU> }
JPU> /**
JPU> * Create a proxy for the {@link SodexoApi} service endpoint
JPU> *
JPU> * @param baseAddress - The base URI of the SDX REST API endpoint.
JPU> * @return The {@link SodexoApi} service endpoint proxy
JPU> *
JPU> * @throws GeneralSecurityException - when retrieving certificate
JPU> info fails
JPU> */
JPU> private static SodexoApi getThreadsafeProxy(String baseAddress)
JPU> throws GeneralSecurityException {
JPU> JacksonJsonProvider provider = new JacksonJsonProvider(new
JPU> CustomObjectMapper());
JPU> List providers = new
JPU> ArrayList();
JPU> providers.add(provider);
JPU> SodexoApi api = JAXRSClientFactory.create(baseAddress,
JPU> SodexoApi.class, providers,true);
JPU> Client client = WebClient.client(api);
JPU> ClientConfiguration config = WebClient.getConfig(client);
JPU> config.getOutInterceptors().add(new
JPU> LoggingOutInterceptor());
JPU> config.getInInterceptors().add(new LoggingInInterceptor());
JPU> addTLSClientParameters(config.getHttpConduit());
JPU> return api;
JPU> }
JPU> /**
JPU>
Re: Plans for Jakarta XML Web Services / Bind API 4.0?
Hi Francesco, Yes, there are plans [1] and also the preliminary work has started [2]. I sadly didn't have much time to work on that recently, but it is moving nonetheless, any help is welcomed! Thanks! [1] https://issues.apache.org/jira/browse/CXF-8671 [2] https://github.com/apache/cxf/pull/1201 Best Regards, Andriy Redko FC> Hi there, FC> I see that the current main branch is set for version 4.0.3-SNAPSHOT and Jakarta XML Web Services / Bind API 3.0 FC> Do we already have plans for CXF 4.1 supporting Jakarta XML Web Services / Bind API 4.0 and related? FC> I was noticing this because some SOAP services based on CXF 4.0.2 / Spring Boot 3.1.0 are not working any more after yesterday release of Spring Boot 3.1.1: I did solve for my own services, but I thought it was better to ask for future plans. FC> TIA FC> Regards.
Re: [VOTE] Apache CXF 3.6.1 and 4.0.2
Hi Francesco, Could you please open an issue (or share more details in a thread)? I don't remember any changes on CXF side there but we definitely did the routine dependency updates for Swagger Core / Swagger UI. Thank you. Best Regards, Andriy Redko > On 06/06/23 20:10, Daniel Kulp wrote: >> This is a vote to release Apache CXF 3.6.1 and 4.0.2. Not a lot has >> changed in these versions, but they do contain critical bug fixes needed in >> order to upgrade Camel to the latest releases. >> Tags: >> https://github.com/apache/cxf/releases/tag/cxf-4.0.2 >> https://github.com/apache/cxf/releases/tag/cxf-3.6.1 >> Staging repositories: >> https://repository.apache.org/content/repositories/orgapachecxf-1191 >> https://repository.apache.org/content/repositories/orgapachecxf-1190 > 0 > I have checked Syncope with the new release candidates and found out that for > some reason the OpenAPI customizer is not working properly any more: in > particular, method javadocs are not being set as OpenAPI endpoint summaries. > This is instead working fine up to 3.6.0. > I don't see enough reasons to stop the release, just a bug to fix with 3.6.3 > / 4.0.3. > Regards.
Re: [VOTE] Apache CXF 3.6.1 and 4.0.2
+1, thanks Dan! Best Regards, Andriy Redko > This is a vote to release Apache CXF 3.6.1 and 4.0.2. Not a lot has changed > in these versions, but they do contain critical bug fixes needed in order to > upgrade Camel to the latest releases. > Tags: > https://github.com/apache/cxf/releases/tag/cxf-4.0.2 > https://github.com/apache/cxf/releases/tag/cxf-3.6.1 > Staging repositories: > https://repository.apache.org/content/repositories/orgapachecxf-1191 > https://repository.apache.org/content/repositories/orgapachecxf-1190 > Here is my +1
Re: Handle Bearer authorization
Hi Jean,
Apologies since I am rarely touching this part of the project, and do have some
knowledge
gaps there. Anyway, the flow I was sure should work actually does not [1]
apparently. There
are 2 security contexts actually:
- javax.ws.rs.core.SecurityContext (or jakarta.ws.rs.core.SecurityContext)
- org.apache.cxf.security.SecurityContext
I was thinking about the latter but due to [1], the injection does not work.
Could you
try to use javax.ws.rs.core.SecurityContext instead please to see what is being
injected
to you?
Thank you.
[1] https://issues.apache.org/jira/browse/CXF-5803
Best Regards,
Andriy Redko
> I did a test where I:
> - created my own SecurityContext implementation
> - in my authentication filter I construct an instance 'sc' of this
> SecurityContext and put in the message using:
> JAXRSUtils.getCurrentMessage().put(SecurityContext.class, sc);
> I tried two ways to obtain this SecurityContext my service methods:
> 1. using annotations:
> Interface: Response
> getOnderneming(@HeaderParam("X-KMO-OPERATION-ID") UUID
> operationId,@PathParam("kboNr") String kboNr,@Context SecurityContext sc);
> Implementation:Response getOnderneming(UUID operationId, String
> kboNr,
> SecurityContext sc){...} 2.without annotations:
> Interface: Response
> getOnderneming(@HeaderParam("X-KMO-OPERATION-ID") UUID
> operationId,@PathParam("kboNr") String kboNr);
> Implementation:Response getOnderneming(UUID operationId, String
> kboNr,
> SecurityContext sc){
> SecurityContext sc =
> JAXRSUtils.getCurrentMessage().get(SecurityContext.class);
> ...
> }Using the annotations (1. above) way doesn't
> work the
> SecurityContext object
> 'sc' is null on entering the getOnderneming() method.
> Without annotations (2. Above) I do get a valid SecurityContext object
> 'sc'.
> Isn't the 'annotations'-way supposed to work this way?
> Regards,
> J.P. Urkens
> -Original Message-
> From: Jean Pierre URKENS
> Sent: vrijdag 2 juni 2023 10:18
> To: 'Andriy Redko'
> Subject: RE: Handle Bearer authorization
> Hi Andriy,
> As far as I understand the filters JwtAuthenticationFilter and
> AbstractJwtAuthenticationFilter the assumption is that a request is received
> with an 'Authentication' header that contains a signed JWT token. The filter
> provides in methods to:
> - validate the signed JWT token
> - to create a SecurityContext (JwtTokenSecurityContext) from it.
> This isn't the situation I am dealing with. I am receiving a request with an
> 'Authorization' header containing 'Bearer '. I've no knowledge
> about the nature of this access_token, nor do I need to since validating
> this access token is done by sending a request to an 'OAuth/OIDC
> introspection endpoint' passing on this access_token. The introspection
> endpoint replies with a scope object (JWT claims object) if the token is
> valid.
> Now I can deal with this situation and create my own SecurityContext
> (extended from ClaimsSecurityContext). What I don't understand is how I get
> this SecurityContext available in my service method.
> I see that the AbstractJwtAuthenticationFilter (line 56) puts the
> constructed SecurityContext in the Message:
> if (securityContext != null) {
> JAXRSUtils.getCurrentMessage().put(SecurityContext.class,
> securityContext);
> }
> Can I simply retrieve this in my service method by calling:
> SecurityContext sc =
> JAXRSUtils.getCurrentMessage().get(SecurityContext.class);
> So no need to add @Context annotations to service methods like e.g.:
> Interface: Response
> getOnderneming(@HeaderParam("X-KMO-OPERATION-ID") UUID
> operationId,@PathParam("kboNr") String kboNr,@Context SecurityContext ctx);
> Implementation:Response getOnderneming(UUID operationId, String kboNr,
> SecurityContext sc){...}
> Regards,
> J.P.
> -Original Message-
> From: Andriy Redko
> Sent: vrijdag 2 juni 2023 0:29
> To: Jean Pierre URKENS ; CXF Dev List
>
> Subject: Re: Handle Bearer authorization
> Hi Jean,
> You should be able to get access to the Bearer and claims using
> JwtAuthenticationFilter + @Context SecurityContext The expected type of the
> security context should be ClaimsSecurityContext, with collection of claims
> being available.
> If the JwtAuthenticationFilter does not work for you (for some reasons), you
> could subclass AbstractJwtAuthenticationFilter.
> Hope it helps, thank you.
> Best Regards,
> Andriy Redko
>> Hi Andriy,
>>
Re: Handle Bearer authorization
Hi Jean,
You should be able to get access to the Bearer and claims using
JwtAuthenticationFilter + @Context SecurityContext
The expected type of the security context should be ClaimsSecurityContext, with
collection of claims being available.
If the JwtAuthenticationFilter does not work for you (for some reasons), you
could subclass AbstractJwtAuthenticationFilter.
Hope it helps, thank you.
Best Regards,
Andriy Redko
> Hi Andriy,
> I am lost in JAXRS JOSE security to figure out how to handle bearer
> authorization. So what I currently did is:
> 1. I created an ContainerRequestFilter to retrieve the Bearer access token
> from the request and query the introspection endpoint which returns the
> JWTClaims
> 2.I added this filter in the Ininterceptor chain
> This works, i.e. the filter is hit and it queries the introspection endpoint
> which returns JWTClaims. The problem is that I need these claims available
> in my service methods and I don't know how to pass them from the
> ContainerRequestFilter to my service method. Thus far I have been looking to
> save the JWTClaims as a property in the ContainerRequestContext which is
> available in my filter and inject this context in my service methods with
> the @Context annotation. As documented in
> https://cxf.apache.org/docs/jax-rs-basics.html#JAXRSBasics-Contextannotations
> a
> number of context types can be injected with the @Context annotation but I
> am not sure I can inject a ContainerRequestContext.
> So I annotated my interface method as:
> Response getOnderneming(
> @HeaderParam("X-KMO-OPERATION-ID")
> @NotNull(message="ERROR_2121") UUID
> operationId,
> @PathParam("kboNr") @NotNull(message="ERROR_2119")
> @Pattern(regexp =
> "^\\d{10}$",message="ERROR_2216") String kboNr,
> @Context ContainerRequestContext ctx);
> And my implementation method as:
> Response getOnderneming(UUID operationId, String kboNr,
> ContainerRequestContext ctx)
> Unfortunately the ctx=null when the implementation method is called.
> So my questions are:
> 1.Is there a way to get the ContainerRequestContext available in my service
> methods?
> 2.If the answer to '1.' Is no how do I pass information constructed in
> request filters to my service methods?
> 3.Generally, is this the correct way to handle bearer authorization? There
> is a lot of stuff in cxf-rt-rs-security-jose-(jaxrs) but I can't really
> figure out how to use it. Anyway it is not sufficient for me to have a
> filter that validates the bearer token. I need the associated 'scope'
> information in my service method as it contains information I'll need in my
> business methods.
> Regards,
> J.P. Urkens
> -Original Message-
> From: Jean Pierre URKENS
> Sent: donderdag 25 mei 2023 9:48
> To: 'Andriy Redko' ; 'dev@cxf.apache.org'
>
> Subject: RE: How to setup multiple JAXRS server endpoints
> Hi Andriy,
> The issue seems to be that the Reader is scanning the implementation classes
> while the @SwaggerDefinition (and all other swagger annotations) were on the
> interface class.
> So
> https://github.com/swagger-api/swagger-core/blob/1.5/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java#L171,
> scanning for @SwaggerDefinition, doesn't get triggered.
> However via
> https://github.com/swagger-api/swagger-core/blob/1.5/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java#L176,
> through reflection, the remaining swagger annotation information is
> retrieved, just not the @SwaggerDefinition.
> So, I moved the @SwaggerDefintion to the implementation class and now it is
> ok.
> Thanks for the advice,
> J.P.
> -Original Message-
> From: Andriy Redko
> Sent: donderdag 25 mei 2023 2:27
> To: Jean Pierre URKENS ; dev@cxf.apache.org
> Subject: Re: How to setup multiple JAXRS server endpoints
> Hi Jean,
> You may run into Swagger JAX-RS scanner limitations, as far as I can tell -
> it checks class annotations for SwaggerDefinition, does not traverse the
> hierarchy [1].
> [1]
> https://github.com/swagger-api/swagger-core/blob/1.5/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java#L194
> Best Regards,
> Andriy Redko
>> RE: How to setup multiple JAXRS server endpoints
>> Still one question );
>> The generated swagger file doesn’t take into account the
>> @SwaggerDefintion on my interface classes?
>> As a test I looked at
>> *https://github.com/apache/cxf/tree/3.6.x-fixes/distribution/src/ma
>> in/release/samples/jax_rs/description_swagger2_web**
>> and** modified** sampl
Re: Releases next week...
Hi Dan, No objections, I will try to address this one [1] over the weekend to get it into 4.0.2, but other issues could be moved off to later releases. Thanks! [1] https://issues.apache.org/jira/browse/CXF-8879 Best Regards, Andriy Redko > The Camel folks are trying to upgrade to the latest CXF releases but have run > into some issues. I’ve fixed the issues on the CXF side, but they need > releases in order for them to do their June releases. Thus, I’m planning on > 4.0.2 and 3.6.1 for early next week. > If there are additional things we need to get in the releases, please let me > know. Thanks!
Re: How to setup multiple JAXRS server endpoints
Hi Jean,
You may run into Swagger JAX-RS scanner limitations, as far as I can tell - it
checks class annotations
for SwaggerDefinition, does not traverse the hierarchy [1].
[1]
https://github.com/swagger-api/swagger-core/blob/1.5/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java#L194
Best Regards,
Andriy Redko
JPU> RE: How to setup multiple JAXRS server endpoints
JPU> Still one question );
JPU> The generated swagger file doesn’t take into account the @SwaggerDefintion
JPU> on my interface classes?
JPU> As a test I looked at
JPU>
*https://github.com/apache/cxf/tree/3.6.x-fixes/distribution/src/main/release/samples/jax_rs/description_swagger2_web**
JPU> and** modified** sample2*
JPU>
<https://github.com/apache/cxf/tree/3.6.x-fixes/distribution/src/main/release/samples/jax_rs/description_swagger2_web
JPU> and modified sample2> as follows:
JPU>@Path("/sample2")
JPU> @Api(value = "/sample2",authorizations=
JPU> {@Authorization(value="bearer")},description = "Sample2 (modified)
JAX-RS
JPU> service with Swagger documentation")
JPU> @SwaggerDefinition(
JPU> info = @Info(
JPU> description = "Sample2 server",
JPU> version="1.0",
JPU> title = "Test2",
JPU> contact = @Contact(name = "J.P. Urkens",email = "
JPU> *jean-pierre.urk...@devoteam.com*
JPU> ")),
JPU> securityDefinition =
JPU> @SecurityDefinition(apiKeyAuthDefinitions=
JPU>
*{@ApiKeyAuthDefinition(key="bearer",in=ApiKeyLocation.HEADER,name="Authorization",description="Use*
JPU> <{@ApiKeyAuthDefinition(key=> the format 'Bearer
JPU> accessToken'")})
JPU> )
JPU> public class Sample2 {...}
JPU> This correctly generates the ‘securityDefintions’ in the swagger file.
JPU> If include the same @SwaggerDefinition and the authorizations on the @Api
JPU> annotation as above in my interface classes then the generated swagger
JPU> file doesn’t
JPU> contain the ‘securityDefintions’ ?
JPU> Any idea what I might be missing?
JPU> Regards,
JPU> J.P.
JPU> -Original Message-
JPU> From: Jean Pierre URKENS
JPU> Sent: dinsdag 23 mei 2023 12:52
JPU> To: 'Andriy Redko' ; 'dev@cxf.apache.org' <
dev@cxf.apache.org>>
JPU> Subject: RE: How to setup multiple JAXRS server endpoints
JPU> Hi Andriy,
JPU> I added the parameter usePathBasedConfig=true to the Swagger2Feature bean
JPU> declarations but still it does generate an empty swagger.yaml for
JPU> interfaces KmopResources and KmopDienstverlener although I noticed that for
JPU> these interfaces the @Path() annotation was commented out (as I included it
JPU> in the server declaration). After providing an empty @Path("") declaration
JPU> on the API interface classes everything worked.
JPU> Thanks for the support.
JPU> -Original Message-
JPU> From: Andriy Redko
JPU> Sent: dinsdag 23 mei 2023 3:42
JPU> To: Jean Pierre URKENS ;
dev@cxf.apache.org
JPU> Subject: Re: How to setup multiple JAXRS server endpoints
JPU> Hi Jean,
JPU> The main problem to configure Swagger property in your particular case is
JPU> that the server address is not "known" or "introspectable" for Swagger.
JPU> Intuitively, it has to be set manually using basePath to the, essentially,
JPU> the server address
JPU> part:
JPU> - /op/services/accounts
JPU> - /op/services/resources
JPU> - /op/services/dienstverlener
JPU> You could read more about other Swagger properties you have asked here:
JPU>
https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Integration-and-Configuration#configuration-properties
JPU> You definitely need to set usePathBasedConfig to "true" otherwise you will
JPU> see the same Swagger specs for all servers. We have a sample here which
JPU> uses 2 jaxrs:server
JPU> instances:
JPU>
https://github.com/apache/cxf/tree/3.6.x-fixes/distribution/src/main/release/samples/jax_rs/description_swagger2_web
JPU> Regarding SwaggerUI, I think the value for each of those should be set to,
JPU> respectively:
JPU> - /op/services/accounts/swagger.yaml
JPU> - /op/services/resources/swagger.yaml
JPU> - /op/services/dienstverlener/swagger.yaml
JPU> I believe this is matching your settings already, except the
JPU> usePathBasedConfig part. The example referred above could be helpful, my
JPU> apologies if I missed something, there are quite a lot of questions :-) The
JPU> fact that the generated Swagger specification is empty is unexpected - it
JPU> should not happen when
Re: How to setup multiple JAXRS server endpoints
Hi Jean, The main problem to configure Swagger property in your particular case is that the server address is not "known" or "introspectable" for Swagger. Intuitively, it has to be set manually using basePath to the, essentially, the server address part: - /op/services/accounts - /op/services/resources - /op/services/dienstverlener You could read more about other Swagger properties you have asked here: https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Integration-and-Configuration#configuration-properties You definitely need to set usePathBasedConfig to "true" otherwise you will see the same Swagger specs for all servers. We have a sample here which uses 2 jaxrs:server instances: https://github.com/apache/cxf/tree/3.6.x-fixes/distribution/src/main/release/samples/jax_rs/description_swagger2_web Regarding SwaggerUI, I think the value for each of those should be set to, respectively: - /op/services/accounts/swagger.yaml - /op/services/resources/swagger.yaml - /op/services/dienstverlener/swagger.yaml I believe this is matching your settings already, except the usePathBasedConfig part. The example referred above could be helpful, my apologies if I missed something, there are quite a lot of questions :-) The fact that the generated Swagger specification is empty is unexpected - it should not happen when JAX-RS resources are properly configured. Thank you. Best Regards, Andriy Redko JPU> RE: How to setup multiple JAXRS server endpoints JPU> Hi Andriy, JPU> I am not quite understanding how to correctly configure the Swagger2Feature. JPU> Referring to the attached cxf-endpoints configuration I (as a test) created JPU> 3 JAXRS server instances: JPU> 1. A* KmopApiServer* server for the* JPU> be.dvtm.aeo.op.sodexo.api.KmopApiService* interface, serving requests for JPU> URI path: JPU>* **///op/services/accounts* JPU>‘op’ = root path of the web application JPU> ‘services’ = servlet path of the CXF-servlet JPU> The address of the server is set to ‘/accounts’ and the @Path(…) JPU> annotation on the interface class was cleared. JPU> 2. A* Kmop**Resources**ApiServer* server for the* be.dvtm.aeo.op.* JPU> *openapi.**api.Kmop**Recources**ApiService* interface, serving requests for JPU> URI path: JPU>* **///op/services/**resources* JPU> The address of the server is set to ‘/resources’ and the @Path(…) JPU> annotation on the interface class was cleared. JPU> 3. A* Kmop**Dienstverlener**Server* server for the* be.dvtm.aeo.op.* JPU> *openapi**.api.Kmop**Dienstverlener**Service* interface, serving requests JPU> for URI path: JPU>* **///op/services/**dienstverlener* JPU> The address of the server is set to ‘/dienstverlener’ and the @Path(…) JPU> annotation on the interface class was cleared. JPU> For each of these server instances I’ve set the Swagger2Feature with JPU> configuration as indicated in the attached cxf-endpoints.xml. JPU> With regard to the configurations for the Swagger2Feature I’ve the JPU> following questions: JPU> a) Referring to *https://cxf.apache.org/docs/swagger2feature.html* JPU> <https://cxf.apache.org/docs/swagger2feature.html> could you clarify on JPU> the following configuration parameters: JPU> *i. ** basePath* – Is this the path to the CXFServlet context (‘ JPU> /op/services’) or to the JAX-RS server instance (e.g. JPU> ‘/op/services/accounts’) or still something else? Is it used to resolve JPU> service classes or is it just for documentation in the swagger file? JPU> *ii.** resourcePackage* – the description mentions ‘package names’ JPU> while the default mentions ‘service classes’? Service 2 and 3 above are JPU> within the same package (generated from the same yaml specification that JPU> included both interfaces). JPU> *iii. ** ig**noreRoutes* – is this taken into account when JPU> scanAllResources=false? JPU> *iv.** swaggerUiConfig* – What is the correct ‘url’ parameter value JPU> (cf. question ‘a’)? JPU> b) What would be the correct URL to generate a swagger.yaml file for JPU> each of the above interfaces? Initially I called: JPU> *i. ** **///op/services/accounts**/swagger.yaml* JPU> *ii.** **///op/services/**resources/swagger.yaml* JPU> *iii. ** **///op/services/**dienstver* JPU> *lener/swagger.yaml* JPU>All three requests delivered the same yaml specification, namely the one JPU> for interface* KmopApiServer*? JPU> c) I tried to debug the processing of the requests under ‘b)’ and this JPU> is done by the class JAXRSInterceptor#processRequest where the MessageImpl JPU> object for request “ii.” looks like the one attached. It finds 3 resource JPU> classes: JPU>be.dvtm.aeo.op.openapi.api.imp
Re: How to setup multiple JAXRS server endpoints
Thank you for invaluable feedback, the documentation has been updated to
have better explanation [1], [2].
[1] https://cwiki.apache.org/confluence/display/CXF20DOC/Swagger2Feature
[2] https://cwiki.apache.org/confluence/display/CXF20DOC/OpenApiFeature
Best Regards,
Andriy Redko
Friday, May 19, 2023, 4:28:05 AM, you wrote:
JPU> This explanation makes sense but that wasn't clear from the WIKI page.
JPU> Regards,
JPU> J.P.
JPU> -Original Message-
JPU> From: Andriy Redko
JPU> Sent: vrijdag 19 mei 2023 3:04
JPU> To: Jean Pierre URKENS ;
dev@cxf.apache.org
JPU> Subject: Re: How to setup multiple JAXRS server endpoints
JPU> Hi Jean,
>> Am I misinterpreting this statement? It sounds to me that it should
>> work with 'queryConfigEnabled=true' instead of 'queryConfigEnabled=false'?
JPU> It could be a bit confusing but I will try to explain (please let me know
if
JPU> it makes sense to you):
JPU> - when 'queryConfigEnabled=false', CXF will dynamically replace the URL in
JPU> SwaggerUI,
JPU>in this respect the value won't be taken from the query string but from
JPU> `url` property
JPU>of the SwaggerUI configuration
JPU> - when 'queryConfigEnabled=true', CXF will do nothing and just forward
JPU> query parameters to
JPU>SwaggerUI, hoping it will somehow take care of it (basically turns off
JPU> the URL replacement),
JPU>that needs custom SwaggerUI distribution
JPU> I hope it explains the behavior, please let me know if it is still
JPU> misleading (so we could improve the documentation). Thank you.
JPU> Best Regards,
JPU> Andriy Redko
JPU>> Hi andriy,
JPU>> I started off with looking at this swagger but prior to that I
JPU>> updated framework versions. I am now on:
JPU>> - CXF v3.5.6
JPU>> - Swagger-UI v4.14.0
JPU>> I noticed things changed with respect to the Swagger2Feature and
JPU>> SwaggerUiConfig due to https://issues.apache.org/jira/browse/CXF-8636.
JPU>> When reading
JPU>> https://cwiki.apache.org/confluence/display/CXF20DOC/Swagger2Featur
JPU>> e#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)
JPU>> I
JPU>> reconfigured the usage of the swagger features as:
JPU>>
JPU>> > class="org.apache.cxf.jaxrs.swagger.ui.SwaggerUiConfig">
JPU>>
JPU>>
JPU>>
JPU>> > class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
JPU>>
JPU>> ref="SwaggerUiConfig"/>
JPU>>
JPU>> With this configuration:
JPU>> * Retrieving the swagger.yaml specification works with the url:
JPU>> http://l-p53-008:8082/idp/rest-services/swagger.yaml ('idp' is the
JPU>> war rootpath and 'rest-services' is the CXF-servlet path)
JPU>> * Loading the Swagger UI with the url:
JPU>> http://l-p53-008:8082/idp/rest-services/api-docs?url=swagger.yaml
JPU>> FAILS ? It loads the petshop store yaml specification.
JPU>> When I change above configuration to:
JPU>>
JPU>> > class="org.apache.cxf.jaxrs.swagger.ui.SwaggerUiConfig">
JPU>>
JPU>>
JPU>>
JPU>> > class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
JPU>>
JPU>> ref="SwaggerUiConfig"/>
JPU>>
JPU>> Then:
JPU>> * Retrieving the swagger.yaml specification works with the url:
JPU>> http://l-p53-008:8082/idp/rest-services/swagger.yaml ('idp' is the
JPU>> war rootpath and 'rest-services' is the CXF-servlet path)
JPU>> * Loading the Swagger UI with the url:
JPU>> http://l-p53-008:8082/idp/rest-services/api-docs?url=swagger.yaml
JPU> SUCCEEDS ?
JPU>> It loads the swagger.yaml specification.
JPU>> The confluence WIKI page above specifically mentions:
JPU>> "Apache CXF prior to 3.4.6 / 3.5.1 passed Swagger UI configuration
JPU>> (url,
JPU>> ...) as query parameters. Starting from Swagger UI 4.1.3, most of
JPU>> query parameters are not accepted anymore (due to security
JPU>> concerns), and Apache CXF employes different strategy and tries to
JPU>> replace the URL dynamically (inside HTML) when serving Swagger UI's
JPU>> front web page. This behaviour could be turned on by setting
JPU>> queryConfigEnabled property of the SwaggerUiConfig to true (the
JPU> default value is false )."
JPU>> Am I misinterpreting this statement? It sounds to me that it should
JPU>> work with 'queryConfigEnabled=true' instead of
JPU> 'queryConfigEnabled=false'?
JPU>> -Original Message-
JPU>> From: Jean Pier
Re: How to setup multiple JAXRS server endpoints
Hi Jean,
> Am I misinterpreting this statement? It sounds to me that it should work
> with 'queryConfigEnabled=true' instead of 'queryConfigEnabled=false'?
It could be a bit confusing but I will try to explain (please let me know
if it makes sense to you):
- when 'queryConfigEnabled=false', CXF will dynamically replace the URL in
SwaggerUI,
in this respect the value won't be taken from the query string but from
`url` property
of the SwaggerUI configuration
- when 'queryConfigEnabled=true', CXF will do nothing and just forward query
parameters to
SwaggerUI, hoping it will somehow take care of it (basically turns off the
URL replacement),
that needs custom SwaggerUI distribution
I hope it explains the behavior, please let me know if it is still misleading
(so we could
improve the documentation). Thank you.
Best Regards,
Andriy Redko
JPU> Hi andriy,
JPU> I started off with looking at this swagger but prior to that I updated
JPU> framework versions. I am now on:
JPU> - CXF v3.5.6
JPU> - Swagger-UI v4.14.0
JPU> I noticed things changed with respect to the Swagger2Feature and
JPU> SwaggerUiConfig due to https://issues.apache.org/jira/browse/CXF-8636.
JPU> When reading
JPU>
https://cwiki.apache.org/confluence/display/CXF20DOC/Swagger2Feature#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)
JPU> I
JPU> reconfigured the usage of the swagger features as:
JPU>
JPU> class="org.apache.cxf.jaxrs.swagger.ui.SwaggerUiConfig">
JPU>
JPU>
JPU>
JPU> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
JPU>
JPU>
JPU>
JPU> With this configuration:
JPU> * Retrieving the swagger.yaml specification works with the url:
JPU> http://l-p53-008:8082/idp/rest-services/swagger.yaml ('idp' is the war
JPU> rootpath and 'rest-services' is the CXF-servlet path)
JPU> * Loading the Swagger UI with the url:
JPU> http://l-p53-008:8082/idp/rest-services/api-docs?url=swagger.yaml FAILS ?
It
JPU> loads the petshop store yaml specification.
JPU> When I change above configuration to:
JPU>
JPU> class="org.apache.cxf.jaxrs.swagger.ui.SwaggerUiConfig">
JPU>
JPU>
JPU>
JPU> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
JPU>
JPU>
JPU>
JPU> Then:
JPU> * Retrieving the swagger.yaml specification works with the url:
JPU> http://l-p53-008:8082/idp/rest-services/swagger.yaml ('idp' is the war
JPU> rootpath and 'rest-services' is the CXF-servlet path)
JPU> * Loading the Swagger UI with the url:
JPU> http://l-p53-008:8082/idp/rest-services/api-docs?url=swagger.yaml SUCCEEDS
?
JPU> It loads the swagger.yaml specification.
JPU> The confluence WIKI page above specifically mentions:
JPU> "Apache CXF prior to 3.4.6 / 3.5.1 passed Swagger UI configuration (url,
JPU> ...) as query parameters. Starting from Swagger UI 4.1.3, most of query
JPU> parameters are not accepted anymore (due to security concerns), and Apache
JPU> CXF employes different strategy and tries to replace the URL dynamically
JPU> (inside HTML) when serving Swagger UI's front web page. This behaviour
could
JPU> be turned on by setting queryConfigEnabled property of the SwaggerUiConfig
JPU> to true (the default value is false )."
JPU> Am I misinterpreting this statement? It sounds to me that it should work
JPU> with 'queryConfigEnabled=true' instead of 'queryConfigEnabled=false'?
JPU> -Original Message-
JPU> From: Jean Pierre URKENS
JPU> Sent: dinsdag 9 mei 2023 9:25
JPU> To: 'Andriy Redko'
JPU> Subject: RE: How to setup multiple JAXRS server endpoints
JPU> Hi Andriy,
JPU> Both servers have not only differences in 'authorization' but also in
JPU> exception handling regarding mapping and validation errors that's why I
JPU> can't use the same JAX-RS server bean for them. I'll have a look at
JPU> customizing the swagger feature and will come back on it but for now
getting
JPU> the server up-and-running is more important.
JPU> Regards,
JPU> J.P. Urkens
JPU> -Original Message-
JPU> From: Andriy Redko
JPU> Sent: maandag 8 mei 2023 23:15
JPU> To: Jean Pierre URKENS ; CXF Dev List
JPU>
JPU> Subject: Re: How to setup multiple JAXRS server endpoints
JPU> Hi Jean,
JPU> Indeed the way you would like to do that is somewhat tricky.
>> So I tried to keep the @Path declaration on the interface classes but
>> changed them to @Path(“”). That does seems to work except the swagger
>> stuff no longer correctly works.
JPU> This is one of the possible options but OpenAPI/Swagger gets confu
Re: Mismatch in content encoding between client and server
Hi Jean,
My apologies for late response but it seems like you have found the issue :-).
However
am a bit surprised by the way you are using Content-Encoding [1]. I would
expect the
charset to be passed along with content type:
Response
.status(Status.OK)
.entity(dvlInfo)
.type(MediaType.APPLICATION_JSON_TYPE.withCharset("UTF-8"))
.build();
But not as Content-Encoding header which seems to be not strictly correct usage
[2].
Hope it makes sense, thank you.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding
[2]
https://stackoverflow.com/questions/17154967/is-content-encoding-being-set-to-utf-8-invalid
Best Regards,
Andriy Redko
JPU> Hi andriy,
JPU> As far as I could trace this the problem seems to be with the logging of
the
JPU> incoming response message only.
JPU> In the method HttpConduit#handleResponseInternal the inMessage has:
JPU>
org.apache.cxf.message.Message.PROTOCOL_HEADERS={content-encoding=[UTF-8],
JPU> Content-Length=[841], content-type=[application/json], Date=[Tue, 16 May
JPU> 2023 10:23:41 GMT], Server=[Jetty(9.4.46.v20220331)]}
JPU> But the call to "updateResponseHeaders(inMessage)" only examines the
JPU> 'content-type' protocol header not the 'content-encoding' header. So the
JPU> inMessage will not have set the 'Message.CONTENT_TYPE' as a result the
JPU> subsequent line of code (line 1682):
JPU> String charset =
JPU> HttpHeaderHelper.findCharset((String)inMessage.get(Message.CONTENT_TYPE));
JPU> returns 'null' resulting in normalizedEncoding=ISO-8859-1.
JPU> Is this a bug?
JPU> J.P.
JPU> -Original Message-
JPU> From: Jean Pierre URKENS
JPU> Sent: maandag 15 mei 2023 16:46
JPU> To: 'Andriy Redko'
JPU> Subject: Mismatch in content encoding between client and server
JPU> Hi Andriy,
JPU> I got my services installed but when performing some local (JUnit) tests I
JPU> notice that I am losing the content-encoding.
JPU> E.g. in below message logging from CXF the country 'België' is passed in
the
JPU> response which has the header content-encoding=UTF-8 set.
JPU> When reading/parsing the response it results in ' België' ?
JPU> What does the server/client need to do to make sure the content is
correctly
JPU> encoded/decoded when:
JPU> - the server writes the result entity in the reponse (I used
JPU>
"Response.status(Status.OK).entity(dvlInfo).type(MediaType.APPLICATION_JSON).encoding("UTF-8").build()")
JPU> - the client reads the result entity from the response (I didn't directly
JPU> see anything to inform the reader that the content is UTF-8 encoded so it
is
JPU> currently read by the client as "resp.readEntity(Dienstverlener.class)")
JPU> Below the CXF message logging:
JPU> KMOP] 2023-05-15 16:29:38,503 [main] INFO $--$
JPU> (org.slf4j.helpers.MarkerIgnoringBase:95) - REQ_OUT
JPU> Address:
JPU>
http://localhost:8185/op/services/dienstverlener/dienstverlener/findErkendByErkNr?erkNr=DV.O235055
JPU> HttpMethod: GET
JPU> Content-Type: application/json
JPU> ExchangeId: 569ef415-99f7-41c2-956e-38e47ea8e4e5
JPU> Headers: {Accept=application/json,
JPU> X-KMO-OPERATION-ID=ceaa4c95-0677-4510-b574-d99d82a45545,
JPU> Content-Type=application/json}
JPU> [KMOP] 2023-05-15 16:29:38,745 [qtp1348937989-29] INFO $--$
JPU> (org.slf4j.helpers.MarkerIgnoringBase:95) - REQ_IN
JPU> Address:
JPU>
http://localhost:8185/op/services/dienstverlener/dienstverlener/findErkendByErkNr?erkNr=DV.O235055
JPU> HttpMethod: GET
JPU> Content-Type: application/json
JPU> ExchangeId: 0c78ff64-8016-4809-adf8-691d786d0dfd
JPU> Headers: {Accept=application/json, Cache-Control=no-cache,
JPU> User-Agent=Apache-CXF/3.5.2,
JPU> X-KMO-OPERATION-ID=ceaa4c95-0677-4510-b574-d99d82a45545,
JPU> connection=keep-alive, content-type=application/json, Host=localhost:8185,
JPU> Pragma=no-cache}
JPU> [KMOP] 2023-05-15 16:29:38,751 [qtp1348937989-29] DEBUG $--$
JPU> (be.xm.base.database.DBPoolManager:192) - Getting DBase connection from
JPU> DBPoolManager for DataSource name=DEFAULT_DS [KMOP] 2023-05-15 16:29:38,752
JPU> [qtp1348937989-29] DEBUG $--$ (be.xm.base.database.DBPoolManager:195) -
JPU> Found DataSource=oracle.jdbc.pool.OracleDataSource@77be656f for DataSource
JPU> name=DEFAULT_DS [KMOP] 2023-05-15 16:29:39,091 [qtp1348937989-29] DEBUG
$--$
JPU> (be.xm.base.database.DBPoolManager:202) - Obtained DBase
JPU> connection(1995619431,autoCommit=true) from datasource DEFAULT_DS in
JPU> 338.9987 milliseconds.
JPU> [KMOP] 2023-05-15 16:29:39,346 [qtp1348937989-29] DEBUG $--$
JPU> (be.xm.base.database.DBHelper:386) - executed SQL-query
JPU> 'selDvlInfoForMMByErkNrAsJson' : obtained DBase resultset in 190.5721
JPU> millis
Re: How to setup multiple JAXRS server endpoints
Hi Jean,
Indeed the way you would like to do that is somewhat tricky.
> So I tried to keep the @Path declaration on the interface classes but changed
> them to @Path(“”). That does seems to work except the swagger stuff no longer
> correctly works.
This is one of the possible options but OpenAPI/Swagger gets confused for a
reason: the path is now implicit (not in the spec).
So how about this option:
- use only one JAX-RS server (address "/")
- host both resources but use @Path("accounts") and @Path("resources") on them
respectively
I see that for @Path("accounts") you need to apply the
"kmopApiAuthorizationFilter", that could be done using
DynamicFeature [1], [2]. If this is not the option and you would prefer to use
2 separate JAX-RS servers, you
may need to provide your own instance of Swagger2Customizer [3], [4] which
allows to transform the OpenAPI/Swagger
on the fly. Please let me know if that would it work for you, thank you.
[1]
https://docs.oracle.com/javaee/7/api/javax/ws/rs/container/DynamicFeature.html
[2]
https://aredko.blogspot.com/2016/02/your-jax-rs-apis-were-not-born-equal.html
[3]
https://cxf.apache.org/javadoc/latest/org/apache/cxf/jaxrs/swagger/Swagger2Customizer.html
[4] https://cxf.apache.org/docs/swagger2feature.html (has customizer property)
Best Regards,
Andriy Redko
> Hi Andriy,
> I am again getting into trouble with server endpoint declarations. Now
> because I am adding additional JAX-RS endpoints.
> The issue is with:
> 1. The 'address' attribute on the declaration in
> combination with
> 2. The 'url-pattern' for the CXFServlet declaration in the web.xml in
> combination with
> 3. The @Path declaration in the interface class in combination with
> 4. The @Path declaration on the interface method in combination with
> So what I had is that my web application deployed under baseUlr 'op' had one
> JAXRS server endpoint with declarations like:
> 1. address="/">
> 2. /services/*
> 3. @Path("accounts") on the public interface class
> 4. @Path("/{authorisationId}/customerFund") on the customerFund
> interface method
> A valid API call would thus be e.g.:
> https://:/op/services/accounts/{authorizationId}/customerFund
> And this works correctly.
> We're now introducing additional JAX-RS service endpoints and now I am
> running into problems. This second endpoint was declared with:
> 1. basePackages="be.dvtm.aeo.op.resources" address="/">
> 2. /services/*
> 3. @Path("resources") on the public interface class
> 4. @Path("/NACE") on the NACE interface method
> So here a valid API call woud be:
> https://:/op/services/resources/NACE.
> The problem is that I can not declare two entries with the
> same ‘address’ as it throws the exception:
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: There
> is an endpoint already running on /.
> So I tried changing the addresses to:
> · address=”accounts” for the restServer
> · address=”resources” for the resourceServer
> But to keep the API-call URLs the same I removed the @Path declaration on the
> interface classes. By doing so the bean declarations no longer
> loads successfully.
> So I tried to keep the @Path declaration on the interface classes but changed
> them to @Path(“”). That does seems to work except the swagger stuff no longer
> correctly works.
> So what is the decent way to setup multiple JAX-RS server endpoints where
> each server has its own configuration regarding supported features:
> · own validation
> · own object and exception mappings
> · own swagger file generation
> · own logging (in separate file if possible)
> I am using Apache CXF-3.5.2 which uses swagger-core v1.6.6 in cooperation
> with swager-ui v4.5.0.
> Below the declarations of my endpoints
> <<...>>
> Thanks for any advice.
> Regards,
> J.P. Urkens
> -Original Message-
> From: Andriy Redko
> Sent: zaterdag 18 juni 2022 1:12
> To: Jean Pierre URKENS ;
> iss...@cxf.apache.org; dev@cxf.apache.org
> Subject: Re: JAXRS server endpoint not gracefully shutdown
> Hi Jean,
>> 1. a jaxrs server on url: '//services/service1'
> Correct, so in the relative form like address="/", the JAX-RS
> endpoint path would be:
> ///[@ApplicationPath]/[@Path]
> The @ApplicationPath is optional in this case.
>> 2. a jaxws service endpoint on '//services/service2'
> The JAX-WS is very different from JAX-RS, essentially the action comes inside
> the SOAP message behind // (@Path /
> @ApplicationPath are not relevant there).
>&
Re: [VOTE] CXF 3.5.6, 3.6.0, 4.0.1
+1, thanks a lot Dan! Best Regards, Andriy Redko DK> It’s been quite a while since the last round of releases and a bunch of work has been done, lots of bug fixes, a couple of new features, etc… DK> Tags: DK> https://github.com/apache/cxf/releases/tag/cxf-4.0.1 ( https://github.com/apache/cxf/commit/ce00f5b861c4dd87b225ee761d4919aa49244b5f ) DK> https://github.com/apache/cxf/releases/tag/cxf-3.6.0 ( https://github.com/apache/cxf/commit/4cf375c5436f3e806293a73a5bb6a8510f7ac961 ) DK> https://github.com/apache/cxf/releases/tag/cxf-3.5.6 ( https://github.com/apache/cxf/commit/eb7a2133a5974efc128a58ad4ed239385da3f5fc ) DK> Staging repos: DK> https://repository.apache.org/content/repositories/orgapachecxf-1187 DK> https://repository.apache.org/content/repositories/orgapachecxf-1188 DK> https://repository.apache.org/content/repositories/orgapachecxf-1189 DK> Here is my +1
Re: New releases?
Sounds great, thanks Dan! >> >> Certainly +1, I will move / close my tickets today. Do you think we could >> also release 3.6.0? Thank you. DK> I’d like to back port the HttpClient stuff to 3.6.0 first, but yes, I’d like to do a 3.6.0 release and then plan on dropping 3.5.x longer term. Supporting Java8 for 3.5 is already beginning to cause issues with libraries that aren’t going to get security updates and such. DK> I’m on Spring Break next week (taking a bunch of Scouts to SeaBase in the Bahamas to sail so will be completely disconnected). Once I get back, I’d be happy to do a bunch of releases. DK> Dan >> >> Best Regards, >>Andriy Redko >> >> >>> It's almost been four months since the last set of releases, what work >>> remains to be done to get new releases out? I'd like to get new XJC >>> and CXF build utils versions out first, as we have upgraded a ton of >>> dependencies there since enabling dependabot. >> >>> Colm. >>
Re: New releases?
Hey Colm, Certainly +1, I will move / close my tickets today. Do you think we could also release 3.6.0? Thank you. Best Regards, Andriy Redko > It's almost been four months since the last set of releases, what work > remains to be done to get new releases out? I'd like to get new XJC > and CXF build utils versions out first, as we have upgraded a ton of > dependencies there since enabling dependabot. > Colm.
Re: cxf 3.5.5 & java 17: missing fault/exception message
Hi Colm,
We sadly still have quite a few places where reflection is used. That's
probably
one of those. There is an ongoing effort to clean up [1] all such occurrences
but
it takes time (and the issues go way beyond just CXF). In general, if there is
an
alternative way to implement the same functionality (without reflection being
used),
we should do that (JIRA ticket is welcomed), but if not - we degrade it (like
in
the case presented, no message since we cannot extract it).
> Are there any other known issues with java 17?
Yes, see please [2] for example.
[1] https://issues.apache.org/jira/browse/CXF-8407
[2] https://issues.apache.org/jira/browse/CXF-8173
Thanks!
Best Regards,
Andriy Redko
> Hi,
> Did anyone look into this - is it already fixed? If not we should have
> a JIRA at least to investigate.
> Colm.
> On Tue, Feb 7, 2023 at 1:08 PM Thomas Matthijs wrote:
>> Hello,
>> There is a difference in behavior between java 11 and java 17. When you
>> throw and exception from a service, the message is lost.
>> I modified one of the example projects to throw an exception:
>> https://github.com/selckin/cxf-exception/blob/master/src/main/java/demo/hw/server/HelloWorldImpl.java#L50
>> With java 11 on the client you will get:
>> demo.hw.server.AccessDeniedException: foobar123
>> at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> On java 17, the message "foobar123" is missing
>> demo.hw.server.AccessDeniedException
>> at
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> Believe this is because the message of the exception is retrieved using
>> reflection that is not allowed on java 17:
>> https://github.com/apache/cxf/blob/b6e3ab83a37cfb777d6eebf9711e552027bde37a/core/src/main/java/org/apache/cxf/interceptor/ClientFaultConverter.java#L197
>> This code is still there even in 4.0.0 which claims to support java 17.
>> Is this a known issue or should I report it as a bug? Or is it accepted that
>> it won't work under java 17+ ?
>> Are there any other known issues with java 17?
>> Thanks
Re: Getting NPE from WebClient#rx with recent 4.0.1-SNAPSHOT artifacts
Hi Francesco, Should be fixed by [1], thanks for heads up! [1] https://github.com/apache/cxf/pull/1206 Best Regards, Andriy Redko > Hi all, > since at least three days, the 4.0.1-SNAPSHOT artifacts are causing an NPE > around > https://github.com/apache/syncope/blob/master/common/keymaster/self/client-self/src/main/java/org/apache/syncope/common/keymaster/client/self/SelfKeymasterOps.java#L66 > with message > java.util.concurrent.CompletionException: jakarta.ws.rs.ProcessingException: > java.lang.NullPointerException: Cannot invoke > "org.apache.cxf.configuration.jsse.TLSClientParameters.getSslContext()" > because "clientParameters" is null > at > java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) > ~[?:?] > at > java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) > ~[?:?] > at > java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1770) > ~[?:?] > at > java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) > ~[?:?] > at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) > ~[?:?] > at > java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) > ~[?:?] > at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) > ~[?:?] > at > java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?] > at > java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) > ~[?:?] > Caused by: jakarta.ws.rs.ProcessingException: java.lang.NullPointerException: > Cannot invoke > "org.apache.cxf.configuration.jsse.TLSClientParameters.getSslContext()" > because "clientParameters" is null > at > org.apache.cxf.jaxrs.client.AbstractClient.checkClientException(AbstractClient.java:638) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.AbstractClient.preProcessResult(AbstractClient.java:612) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1149) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1086) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:931) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:900) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:460) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.SyncInvokerImpl.method(SyncInvokerImpl.java:150) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.CompletionStageRxInvokerImpl.lambda$method$0(CompletionStageRxInvokerImpl.java:147) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) > ~[?:?] > As said, the same code was working fine until 3 days ago. > I suppose this is the consequence of recent commits to CXF master: do we need > to update something on Syncope side or this is something to fix in CXF? > TIA > Regards.
Re: Getting NPE from WebClient#rx with recent 4.0.1-SNAPSHOT artifacts
Hi Francesco, Thanks a lot for heads up, I saw a few commits from @Dan on March 17 [1] related to client side changed, those (potentially) could cause the regression. @Dan if you have time to take a look, would be great, otherwise I should be able to check it over the weekend. Thank you. [1] https://github.com/apache/cxf/commits/main Best Regards, Andriy Redko > Hi all, > since at least three days, the 4.0.1-SNAPSHOT artifacts are causing an NPE > around > https://github.com/apache/syncope/blob/master/common/keymaster/self/client-self/src/main/java/org/apache/syncope/common/keymaster/client/self/SelfKeymasterOps.java#L66 > with message > java.util.concurrent.CompletionException: jakarta.ws.rs.ProcessingException: > java.lang.NullPointerException: Cannot invoke > "org.apache.cxf.configuration.jsse.TLSClientParameters.getSslContext()" > because "clientParameters" is null > at > java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) > ~[?:?] > at > java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) > ~[?:?] > at > java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1770) > ~[?:?] > at > java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) > ~[?:?] > at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) > ~[?:?] > at > java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) > ~[?:?] > at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) > ~[?:?] > at > java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?] > at > java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) > ~[?:?] > Caused by: jakarta.ws.rs.ProcessingException: java.lang.NullPointerException: > Cannot invoke > "org.apache.cxf.configuration.jsse.TLSClientParameters.getSslContext()" > because "clientParameters" is null > at > org.apache.cxf.jaxrs.client.AbstractClient.checkClientException(AbstractClient.java:638) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.AbstractClient.preProcessResult(AbstractClient.java:612) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1149) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1086) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:931) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:900) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:460) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.SyncInvokerImpl.method(SyncInvokerImpl.java:150) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > org.apache.cxf.jaxrs.client.CompletionStageRxInvokerImpl.lambda$method$0(CompletionStageRxInvokerImpl.java:147) > ~[cxf-rt-rs-client-4.0.1-SNAPSHOT.jar:4.0.1.SNAPSHOT] > at > java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) > ~[?:?] > As said, the same code was working fine until 3 days ago. > I suppose this is the consequence of recent commits to CXF master: do we need > to update something on Syncope side or this is something to fix in CXF? > TIA > Regards.
Re: [RESULT] [VOTE] Apache CXF 4.0.0
Hey guys, Sorry about that, I have updated the following pages [1], [2], [3], the website should be updated shortly. Please let me know if I've missed something. [1] https://cwiki.apache.org/confluence/display/CXF/CXF+4.0.0+Release+Notes [2] https://cwiki.apache.org/confluence/display/CXF/Index [3] https://cwiki.apache.org/confluence/display/CXF/Download Thanks for bringing it up! Best Regards, Andriy Redko AS> Folks, AS> it looks weird to see CXF 4 artifacts on Maven Central since Dec 22nd but AS> no announcement on the website. Am I missing anything here? Who is going to AS> work on the remaining steps? Jim or me can likely help if it's just a AS> matter of not having time for this ;-) AS> Cheers AS> On Fri, Jan 13, 2023 at 4:05 AM Andrey Redko wrote: >> Hey Jim, >> >> Happy New Year! I think Dan mentioned he was going on vacation for a few >> weeks. I am not sure he is back, @Colm do you know by any chance? >> >> Thank you! >> >> Best Regards, >> Andriy Redko >> >> On Thu, Jan 12, 2023, 9:52 PM Jim Ma wrote: >> >> > Happy new year, everyone ! >> > >> > I see the CXF 4.0.0 release note isn't finalized : >> > https://issues.apache.org/jira/projects/CXF/versions/12351115 >> > <https://issues.apache.org/jira/projects/CXF/versions/12351115>, >> > and we didn't announce this release in https://cxf.apache.org/ >> > <https://cxf.apache.org/>. Is anyone working on this ? >> > >> > Thanks, >> > Jim >> > >> > On Thu, Dec 22, 2022 at 9:20 PM Daniel Kulp wrote: >> > >> > > With 9 +1 votes, this vote passes. >> > > >> > > Thanks! >> > > Dan >> > > >> > > >> > > > On Dec 18, 2022, at 10:26 AM, Daniel Kulp wrote: >> > > > >> > > > This is a vote to release CXF 4.0.0.This is a major release that >> > > completely changes the API from using the older javax.* packages to >> using >> > > the jakarta.* versions. It also updates everything to more modern >> > > dependencies (Jetty 11, Spring 6, etc…). This also raises the minimum >> > JDK >> > > level to Java 11, but in some cases Java 17 is required (example: >> Spring >> > > 6/SpringBoot 3). >> > > > >> > > > Staging repo: >> > > > >> https://repository.apache.org/content/repositories/orgapachecxf-1185/ >> > > > >> > > > Tag: >> > > > >> > > >> > >> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=9914621a3d875d8d5371544b0e92b11a10cd2fd9 >> > > > >> > > > >> > > > >> > > > This vote will be open for 72 hours. Here is my +1. >> > > > >> > > > -- >> > > > Daniel Kulp >> > > > dk...@apache.org >> > > > Talend - https://talend.com >> > > > >> > > >> > > -- >> > > Daniel Kulp >> > > dk...@apache.org <mailto:dk...@apache.org> >> > > Talend - https://talend.com <https://talend.com/> >> > > >> > > >> > >>
Re: CXF branch 3.5.x-fixes failure WSDiscoveryClientTest.testMultiResponses
Hi Gary, This test case is trying to use the UDP broadcast + multicast for discovery purposes and it seems like on Windows the network interface being picked up does not support that. On my local machine (Windows 10) is fails randomly since I do have a few network interfaces, some of them work but some do not (the reason is not clear to me yet, all of them report to support multicast happily). I will try to troubleshoot that, thank you. Best Regards, Andriy Redko GDG> Hi All: GDG> Any thoughts on getting the test below to pass? GDG> I am using: GDG> Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29) GDG> Maven home: C:\java\apache-maven-3.8.7 GDG> Java version: 1.8.0_352, vendor: Temurin, runtime: C:\Program Files\Eclipse Adoptium\jdk-8.0.352.8-hotspot\jre GDG> Default locale: en_US, platform encoding: Cp1252 GDG> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" GDG> Microsoft Windows [Version 10.0.19044.2364] GDG> [INFO] --- GDG> [INFO] T E S T S GDG> [INFO] --- GDG> [INFO] Running org.apache.cxf.ws.discovery.WSDiscoveryClientTest GDG> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.534 s <<< FAILURE! - in org.apache.cxf.ws.discovery.WSDiscoveryClientTest GDG> [ERROR] org.apache.cxf.ws.discovery.WSDiscoveryClientTest.testMultiResponses Time elapsed: 2.47 s <<< ERROR! GDG> javax.xml.ws.soap.SOAPFaultException: Could not receive Message. GDG> at org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:285) GDG> at org.apache.cxf.jaxws.DispatchImpl.invokeAsync(DispatchImpl.java:463) GDG> at org.apache.cxf.ws.discovery.WSDiscoveryClient.probe(WSDiscoveryClient.java:382) GDG> at org.apache.cxf.ws.discovery.WSDiscoveryClientTest.testMultiResponses(WSDiscoveryClientTest.java:155) GDG> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) GDG> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) GDG> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) GDG> at java.lang.reflect.Method.invoke(Method.java:498) GDG> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) GDG> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) GDG> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) GDG> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) GDG> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) GDG> at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) GDG> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) GDG> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) GDG> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) GDG> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) GDG> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) GDG> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) GDG> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) GDG> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) GDG> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) GDG> at org.junit.runners.ParentRunner.run(ParentRunner.java:413) GDG> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) GDG> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) GDG> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) GDG> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) GDG> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) GDG> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) GDG> at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) GDG> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) GDG> Caused by: javax.xml.ws.WebServiceException: Could not receive Message. GDG> at org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:267) GDG> at org.apache.cxf.jaxws.DispatchImpl.access$000(DispatchImpl.java:98) GDG> at org.apache.cxf.jaxws.DispatchImpl$1.ma
Re: [VOTE] Apache CXF 4.0.0
+1, thanks Dan! Best Regards, Andriy Redko > +1 > Go Argentina! > Jeff >> On Dec 18, 2022, at 8:26 AM, Daniel Kulp wrote: >> This is a vote to release CXF 4.0.0. This is a major release that >> completely changes the API from using the older javax.* packages to using >> the jakarta.* versions. It also updates everything to more modern >> dependencies (Jetty 11, Spring 6, etc…). This also raises the minimum JDK >> level to Java 11, but in some cases Java 17 is required (example: Spring >> 6/SpringBoot 3). >> Staging repo: >> https://repository.apache.org/content/repositories/orgapachecxf-1185/ >> Tag: >> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=9914621a3d875d8d5371544b0e92b11a10cd2fd9 >> This vote will be open for 72 hours. Here is my +1.
Re: CXF 4.0.0 jakarta release
Hey guys, We're getting closer, here is what's left: DK>> jaxrs/basic_oidc DK>> jaxrs/big_query DK>> corba (weird ORB errors with java17, missing transaction classes with java11) DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) It is very likely we would have to drop description_openapi_microprofile_spring (for the time being) since Geronimo OpenAPI does not support Microprofile OpenApi 3.0 yet (I will double check). I am picking these ones to finish up: DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK>> jax_rs/spring_boot_scan DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables Thank you. Best Regards, Andriy Redko AR> Fixed these ones: DK>> jms_spring_config - hangs on client stop DK>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis) DK>> jms_pubsub - broker doesn't start AR> And will pick these ones: DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK>> jax_rs/spring_boot_scan DK>> jax_rs/tracing_brave DK>> jax_rs/tracing_opentracing DK>> jax_rs/tracing_opentracing_camel DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues AR> Here is what's left: DK>> jaxrs/basic_oidc DK>> jaxrs/big_query DK>> corba (weird ORB errors with java17, missing transaction classes with java11) DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) AR> Thanks! AR> Best Regards, AR> Andriy Redko DK>>> jaxws_graalvm DK>>> jaxws_graalvm_dynamic DK>>> jax_rs/graalvm_basic AR>> Also fixed: DK>>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found DK>>> jax_rs/description_openapi_v3_web - classpath? Jackson not found DK>>> jax_rs/sse_tomcat - classpath? Jackson not found AR>> And will pick these ones: DK>>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK>>> jms_spring_config - hangs on client stop DK>>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis) DK>>> jms_pubsub - broker doesn't start DK>>> jax_rs/spring_boot_scan DK>>> jax_rs/tracing_brave DK>>> jax_rs/tracing_opentracing DK>>> jax_rs/tracing_opentracing_camel DK>>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK>>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK>>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues AR>> Here is what's left: DK>>> jaxrs/basic_oidc DK>>> jaxrs/big_query DK>>> corba (weird ORB errors with java17, missing transaction classes with java11) DK>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) AR>> [1] https://issues.apache.org/jira/browse/CXF-8743 AR>> Thanks! AR>> Best Regards, AR>> Andriy Redko DK>>> I finished going through all the samples.This is what’s left: DK>>> Problems: DK>>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK>>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK>>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found DK>>> jax_rs/description_openapi_v3_web - classpath? Jackson not found DK>>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues DK>>> jax_rs/sse_tomcat - classpath? Jackson not found DK>>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK>>> corba (weird ORB errors with java17, missing transaction classes with java11) DK>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) DK>>> jms_spring_config -
Re: CXF 4.0.0 jakarta release
Fixed these ones: DK> jms_spring_config - hangs on client stop DK> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis) DK> jms_pubsub - broker doesn't start And will pick these ones: DK> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK> jax_rs/spring_boot_scan DK> jax_rs/tracing_brave DK> jax_rs/tracing_opentracing DK> jax_rs/tracing_opentracing_camel DK> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues Here is what's left: DK> jaxrs/basic_oidc DK> jaxrs/big_query DK> corba (weird ORB errors with java17, missing transaction classes with java11) DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) Thanks! Best Regards, Andriy Redko DK>> jaxws_graalvm DK>> jaxws_graalvm_dynamic DK>> jax_rs/graalvm_basic AR> Also fixed: DK>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found DK>> jax_rs/description_openapi_v3_web - classpath? Jackson not found DK>> jax_rs/sse_tomcat - classpath? Jackson not found AR> And will pick these ones: DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK>> jms_spring_config - hangs on client stop DK>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis) DK>> jms_pubsub - broker doesn't start DK>> jax_rs/spring_boot_scan DK>> jax_rs/tracing_brave DK>> jax_rs/tracing_opentracing DK>> jax_rs/tracing_opentracing_camel DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues AR> Here is what's left: DK>> jaxrs/basic_oidc DK>> jaxrs/big_query DK>> corba (weird ORB errors with java17, missing transaction classes with java11) DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) AR> [1] https://issues.apache.org/jira/browse/CXF-8743 AR> Thanks! AR> Best Regards, AR> Andriy Redko DK>> I finished going through all the samples.This is what’s left: DK>> Problems: DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found DK>> jax_rs/description_openapi_v3_web - classpath? Jackson not found DK>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues DK>> jax_rs/sse_tomcat - classpath? Jackson not found DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK>> corba (weird ORB errors with java17, missing transaction classes with java11) DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) DK>> jms_spring_config - hangs on client stop DK>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis) DK>> jms_pubsub - broker doesn't start DK>> Did not try: (M1 mac, not "native-image") DK>> jaxws_graalvm DK>> jaxws_graalvm_dynamic DK>> jax_rs/graalvm_basic DK>> Did not try: (other setup things required) (ex: google dev id, docker, etc..) DK>> jaxrs/basic_oidc DK>> jaxrs/big_query DK>> jax_rs/spring_boot_scan DK>> jax_rs/tracing_brave DK>> jax_rs/tracing_opentracing DK>> jax_rs/tracing_opentracing_camel DK>> Feel free to grab something and fix it. :) DK>> Dan >>> On Dec 12, 2022, at 4:21 PM, Daniel Kulp wrote: >>> >>>> >>>> I passed through all samples to make sure they are compilable and >>>> buildable, but I only >>>> run a handful of them, it would be great to check that all samples do >>>> actually work. >>>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like >>>> a plan? If >>>> yes, I will create an umbrella issue so we co
Re: CXF 4.0.0 jakarta release
Fixed (as part of [1]) all GraalVM samples: DK> jaxws_graalvm DK> jaxws_graalvm_dynamic DK> jax_rs/graalvm_basic Also fixed: DK> jax_rs/description_openapi_v3_spring - classpath? Jackson not found DK> jax_rs/description_openapi_v3_web - classpath? Jackson not found DK> jax_rs/sse_tomcat - classpath? Jackson not found And will pick these ones: DK> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK> jms_spring_config - hangs on client stop DK> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis) DK> jms_pubsub - broker doesn't start DK> jax_rs/spring_boot_scan DK> jax_rs/tracing_brave DK> jax_rs/tracing_opentracing DK> jax_rs/tracing_opentracing_camel DK> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues Here is what's left: DK> jaxrs/basic_oidc DK> jaxrs/big_query DK> corba (weird ORB errors with java17, missing transaction classes with java11) DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) [1] https://issues.apache.org/jira/browse/CXF-8743 Thanks! Best Regards, Andriy Redko DK> I finished going through all the samples.This is what’s left: DK> Problems: DK> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue DK> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables DK> jax_rs/description_openapi_v3_spring - classpath? Jackson not found DK> jax_rs/description_openapi_v3_web - classpath? Jackson not found DK> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues DK> jax_rs/sse_tomcat - classpath? Jackson not found DK> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample DK> corba (weird ORB errors with java17, missing transaction classes with java11) DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) DK> jms_spring_config - hangs on client stop DK> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis) DK> jms_pubsub - broker doesn't start DK> Did not try: (M1 mac, not "native-image") DK> jaxws_graalvm DK> jaxws_graalvm_dynamic DK> jax_rs/graalvm_basic DK> Did not try: (other setup things required) (ex: google dev id, docker, etc..) DK> jaxrs/basic_oidc DK> jaxrs/big_query DK> jax_rs/spring_boot_scan DK> jax_rs/tracing_brave DK> jax_rs/tracing_opentracing DK> jax_rs/tracing_opentracing_camel DK> Feel free to grab something and fix it. :) DK> Dan >> On Dec 12, 2022, at 4:21 PM, Daniel Kulp wrote: >> >>> >>> I passed through all samples to make sure they are compilable and >>> buildable, but I only >>> run a handful of them, it would be great to check that all samples do >>> actually work. >>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like >>> a plan? If >>> yes, I will create an umbrella issue so we could track individual samples. >>> Thank you >>> for bringing this on up. >> >> I went through all the other samples (non JMS and non RS) and fixed up the >> “easy” ones. What’s left: >> >> corba (weird ORB errors with java17, missing transaction classes with java11) >> js_browser_client_java_first (ClassNotFoundException: >> org.eclipse.jetty.util.resource.FileResource) >> sts (some spring bean definition issues) >> ws_notification (jms broker issues) >> ws_transaction (spring test runner doesn't actually run the test, not sure >> why) >> >> >> Did not try: (M1 mac, no "native-image” available) >> jaxws_graalvm >> jaxws_graalvm_dynamic >> >> >> >> Not sure what to do with the CORBA things…. Likely could add the >> javax.transaction things and get it to run with Java11. Might be a case >> where the example works on 11 and not 17. >> >> >> Dan >> >> >> >> >> >>> >>> Best Regards, >>> Andriy Redko >>> >>> >>>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of >>>>> Spring 6), >>>>> we also need JD
Re: CXF 4.0.0 jakarta release
Thanks Dan, Here is my update. I have fixed: ws_notification (jms broker issues) ws_transaction (spring test runner doesn't actually run the test, not sure why) I will be working on: jaxws_graalvm jaxws_graalvm_dynamic Not looked yet: corba (weird ORB errors with java17, missing transaction classes with java11) js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) sts (some spring bean definition issues) Thanks. Best Regards, Andriy Redko >> >> I passed through all samples to make sure they are compilable and buildable, >> but I only >> run a handful of them, it would be great to check that all samples do >> actually work. >> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a >> plan? If >> yes, I will create an umbrella issue so we could track individual samples. >> Thank you >> for bringing this on up. DK> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left: DK> corba (weird ORB errors with java17, missing transaction classes with java11) DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource) DK> sts (some spring bean definition issues) DK> ws_notification (jms broker issues) DK> ws_transaction (spring test runner doesn't actually run the test, not sure why) DK> Did not try: (M1 mac, no "native-image” available) DK> jaxws_graalvm DK> jaxws_graalvm_dynamic DK> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17. DK> Dan >> >> Best Regards, >>Andriy Redko >> >> >>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of >>>> Spring 6), >>>> we also need JDK-17 to compile (same reason), but when Spring is not >>>> involved (it is >>>> optional by and large), JDK-11 is sufficient. We do have a number of >>>> samples (bundled >>>> with distribution) that run on JDK-11 with no issues. Please let me know >>>> your conclusions >>>> and if you need any help or pointers here. Thank you. >> >> DK> Found a minor class loader issue in cxf-core which fixed a couple of >> things related to using spring5. (Non-servlet spring 5) I’ll get that >> committed shortly once test run. >> >> DK> That said, has anyone actually gone through the samples and actually >> made sure they work? They compile OK (with java17), but many don’t actually >> work. None of the JMS samples seem to work at all.Some are still >> setup to use activemq (might be OK, but the class path doesn’t have >> activemq) and others that are setup for Artemis don’t have proper spring >> bean configuration for it and the connection factories cannot be created. >> I’ve only tested a few samples, but so far I’m seeing a bunch of issues. >> >> >> >> DK> Dan >> >> >>>> >>>> Best Regards, >>>> Andriy Redko >>>> >>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma wrote: >>>>>> >>>>>> Hi Andriy, >>>>>> Thanks for the quick update. Good to see this is running with the jenkins >>>>>> pipeline and all tests are green. >>>>>> Did it include all things for the CXF 4.0.0 release ? >>>> >>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic >>>> tests don’t work with java11, but I didn’t really get time to figure out >>>> why yet. I’m trying to figure out if it’s still actually compatible with >>>> java11 or not. If not, we should bump the jdk.version up. >>>> >>>> >>>> DK> Dan >>>> >>>> >>>>>> >>>>>> Thanks, >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko wrote: >>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> I disabled this build (and >>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well) >>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were >>>>>>> quite useful when >>>>>>> the ma
Re: CXF 4.0.0 jakarta release
Hi Dan, I passed through all samples to make sure they are compilable and buildable, but I only run a handful of them, it would be great to check that all samples do actually work. I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If yes, I will create an umbrella issue so we could track individual samples. Thank you for bringing this on up. Best Regards, Andriy Redko >> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of >> Spring 6), >> we also need JDK-17 to compile (same reason), but when Spring is not >> involved (it is >> optional by and large), JDK-11 is sufficient. We do have a number of samples >> (bundled >> with distribution) that run on JDK-11 with no issues. Please let me know >> your conclusions >> and if you need any help or pointers here. Thank you. DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run. DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all.Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues. DK> Dan >> >> Best Regards, >>Andriy Redko >> >> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma wrote: >>>> >>>> Hi Andriy, >>>> Thanks for the quick update. Good to see this is running with the jenkins >>>> pipeline and all tests are green. >>>> Did it include all things for the CXF 4.0.0 release ? >> >> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic >> tests don’t work with java11, but I didn’t really get time to figure out why >> yet. I’m trying to figure out if it’s still actually compatible with >> java11 or not. If not, we should bump the jdk.version up. >> >> >> DK> Dan >> >> >>>> >>>> Thanks, >>>> Jim >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko wrote: >>>> >>>>> Hi Jim, >>>>> >>>>> I disabled this build (and >>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well) >>>>> because we run pipeline matrix [1] against both JDKs. These builds were >>>>> quite useful when >>>>> the main branch was unstable, but the pipeline should be sufficient now. >>>>> Please let me >>>>> know if you have any concerns, thank you. >>>>> >>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/ >>>>> >>>>> Best Regards, >>>>> Andriy Redko >>>>> >>>>> JM> Did we already start the 4.0 release work ? >>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now : >>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build >>>>> result >>>>> JM> was 7 days ago. >>>>> >>>>> >>>>> >>>>> >>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko wrote: >>>>> >>>>>>> Hi Colm, >>>>>>> >>>>>>> I still wait for review on [1], if you or/and Dan could take a look, >>>>>>> would be great. The [2] could go in today but no user response on [3], >>>>>>> may need a bump to next version. Thank you. >>>>>>> >>>>>>> [1] https://github.com/apache/cxf/pull/1033 >>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799 >>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798 >>>>>>> >>>>>>> Best Regards, >>>>>>> Andriy Redko >>>>>>> >>>>>>> COh> Hi Andriy, >>>>>>> >>>>>>> COh> What's the status of these open issues? Can they be merged today or >>>>>>> COh> else bumped to the next release? >>>>>>> >>>>>>> COh> Colm. >>>>>
Re: CXF 4.0.0 jakarta release
Hi Dan, Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6), we also need JDK-17 to compile (same reason), but when Spring is not involved (it is optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled with distribution) that run on JDK-11 with no issues. Please let me know your conclusions and if you need any help or pointers here. Thank you. Best Regards, Andriy Redko DK> On Dec 11, 2022, at 9:36 PM, Jim Ma wrote: >> >> Hi Andriy, >> Thanks for the quick update. Good to see this is running with the jenkins >> pipeline and all tests are green. >> Did it include all things for the CXF 4.0.0 release ? DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up. DK> Dan >> >> Thanks, >> Jim >> >> >> >> >> >> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko wrote: >> >>> Hi Jim, >>> >>> I disabled this build (and >>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well) >>> because we run pipeline matrix [1] against both JDKs. These builds were >>> quite useful when >>> the main branch was unstable, but the pipeline should be sufficient now. >>> Please let me >>> know if you have any concerns, thank you. >>> >>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/ >>> >>> Best Regards, >>>Andriy Redko >>> >>> JM> Did we already start the 4.0 release work ? >>> JM> I saw the CI build for CXF 4.0.0 is disabled now : >>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build >>> result >>> JM> was 7 days ago. >>> >>> >>> >>> >>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko wrote: >>> >>>>> Hi Colm, >>>>> >>>>> I still wait for review on [1], if you or/and Dan could take a look, >>>>> would be great. The [2] could go in today but no user response on [3], >>>>> may need a bump to next version. Thank you. >>>>> >>>>> [1] https://github.com/apache/cxf/pull/1033 >>>>> [2] https://issues.apache.org/jira/browse/CXF-8799 >>>>> [3] https://issues.apache.org/jira/browse/CXF-8798 >>>>> >>>>> Best Regards, >>>>>Andriy Redko >>>>> >>>>> COh> Hi Andriy, >>>>> >>>>> COh> What's the status of these open issues? Can they be merged today or >>>>> COh> else bumped to the next release? >>>>> >>>>> COh> Colm. >>>>> >>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko >>> wrote: >>>>>>> >>>>>>> Hey guys, >>>>>>> >>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them >>>>>>> pull requests are opened, waiting for minor changes / confirmations >>>>> fixes work. >>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate >>> the >>>>>>> leak of the REMOVED_MARKER. Thanks! >>>>>>> >>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798 >>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799 >>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796 >>>>>>> [4] https://github.com/apache/cxf/pull/1033 >>>>>>> >>>>>>> Best Regards, >>>>>>>Andriy Redko >>>>>>> >>>>>>>> I'm done now in terms of any remaining fixes for the next >>>>>>>> releases...not sure if @Andriy Redko has anything else planned? >>>>>>> >>>>>>>> Colm. >>>>>>> >>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh >>>>>>>> wrote: >>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on >>> two >>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to >>> go. >>>>>>>>> Colm. >>>>>>>>> On Wed, Nov
Re: CXF 4.0.0 jakarta release
Hi Jim, I disabled this build (and https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well) because we run pipeline matrix [1] against both JDKs. These builds were quite useful when the main branch was unstable, but the pipeline should be sufficient now. Please let me know if you have any concerns, thank you. [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/ Best Regards, Andriy Redko JM> Did we already start the 4.0 release work ? JM> I saw the CI build for CXF 4.0.0 is disabled now : JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build result JM> was 7 days ago. JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko wrote: >> Hi Colm, >> >> I still wait for review on [1], if you or/and Dan could take a look, >> would be great. The [2] could go in today but no user response on [3], >> may need a bump to next version. Thank you. >> >> [1] https://github.com/apache/cxf/pull/1033 >> [2] https://issues.apache.org/jira/browse/CXF-8799 >> [3] https://issues.apache.org/jira/browse/CXF-8798 >> >> Best Regards, >> Andriy Redko >> >> COh> Hi Andriy, >> >> COh> What's the status of these open issues? Can they be merged today or >> COh> else bumped to the next release? >> >> COh> Colm. >> >> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko wrote: >> >> >> >> Hey guys, >> >> >> >> I have only these 3 issues to wrap up [1], [2], [3], for all of them >> >> pull requests are opened, waiting for minor changes / confirmations >> fixes work. >> >> @Dan @Colm appreciate your input on [4] please, this is to eliminate the >> >> leak of the REMOVED_MARKER. Thanks! >> >> >> >> [1] https://issues.apache.org/jira/browse/CXF-8798 >> >> [2] https://issues.apache.org/jira/browse/CXF-8799 >> >> [3] https://issues.apache.org/jira/browse/CXF-8796 >> >> [4] https://github.com/apache/cxf/pull/1033 >> >> >> >> Best Regards, >> >> Andriy Redko >> >> >> >> > I'm done now in terms of any remaining fixes for the next >> >> > releases...not sure if @Andriy Redko has anything else planned? >> >> >> >> > Colm. >> >> >> >> > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh >> >> > wrote: >> >> >> It works for me as well. I'm coordinating with @Andriy Redko on two >> >> >> fixes that remain for 3.5.x/3.4.x and then we should be good to go. >> >> >> Colm. >> >> >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma >> wrote: >> >> >>> Thanks Andriy and Dan ! >> >> >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko >> wrote: >> >> >>>> Works for me, thanks a lot Dan! >> >> >> >> >>>> Best Regards, >> >> >>>> Andriy Redko >> >> >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp >> wrote: >> >> >>>>>> I don't think anything blocking is left, +1 to move forward! >> @Colm @Dan >> >> >> >> >>>>> do >> >> >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as >> well? With >> >> >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), >> the 3.4.x >> >> >>>>> is >> >> >>>>>> approaching EOL quickly, could be the last release. >> >> >>>>> I was definitely planning on doing 3.4/3.5 releases sometime >> before the >> >> >>>>> end of the year. Thus, we could do a full set of releases. I >> have a >> >> >>>>> bunch of things happening this week, but would next Monday work >> for >> >> >>>>> everyone? That would give a week to get any final updates in. >> >> >>>>> Dan >> >> >>>>>> Thank you guys! >> >> >>>>>> Best Regards, >> >> >>>>>>Andriy Redko >> >> >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma >> wrote: >> >> >>>>>>> Hi Andriy, >> >> >>>>>>> Can we start the release work if there isn't the major thing >> left we >> >> >>>>> need >> >> >>>>>>> to include in CXF 4.0.0 re
Re: [VOTE] CXF 3.5.5 and 3.4.10
+1, thanks a lot Dan! Best Regards, Andriy Redko DK> I was only able to get the 3.4 and 3.5 patch releases built today, but I’d like to go ahead and get the vote started for them. DK> This is a vote to release the latest set of patched for CXF. DK> Staging repositories: DK> 3.5.5 DK> https://repository.apache.org/content/repositories/orgapachecxf-1183/ DK> 3.4.10 DK> https://repository.apache.org/content/repositories/orgapachecxf-1184/ DK> Tags: DK> 3.5.5 DK> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=cad47a4176229e22404f4c6ebdadfa561b33a021 DK> 3.4.10 DK> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=d091e556d1a28580a7089bbb142700be015c89f4 DK> Here is my +1
Re: CXF 4.0.0 jakarta release
Hi Colm, I still wait for review on [1], if you or/and Dan could take a look, would be great. The [2] could go in today but no user response on [3], may need a bump to next version. Thank you. [1] https://github.com/apache/cxf/pull/1033 [2] https://issues.apache.org/jira/browse/CXF-8799 [3] https://issues.apache.org/jira/browse/CXF-8798 Best Regards, Andriy Redko COh> Hi Andriy, COh> What's the status of these open issues? Can they be merged today or COh> else bumped to the next release? COh> Colm. COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko wrote: >> >> Hey guys, >> >> I have only these 3 issues to wrap up [1], [2], [3], for all of them >> pull requests are opened, waiting for minor changes / confirmations fixes >> work. >> @Dan @Colm appreciate your input on [4] please, this is to eliminate the >> leak of the REMOVED_MARKER. Thanks! >> >> [1] https://issues.apache.org/jira/browse/CXF-8798 >> [2] https://issues.apache.org/jira/browse/CXF-8799 >> [3] https://issues.apache.org/jira/browse/CXF-8796 >> [4] https://github.com/apache/cxf/pull/1033 >> >> Best Regards, >> Andriy Redko >> >> > I'm done now in terms of any remaining fixes for the next >> > releases...not sure if @Andriy Redko has anything else planned? >> >> > Colm. >> >> > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh >> > wrote: >> >> It works for me as well. I'm coordinating with @Andriy Redko on two >> >> fixes that remain for 3.5.x/3.4.x and then we should be good to go. >> >> Colm. >> >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma wrote: >> >>> Thanks Andriy and Dan ! >> >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko wrote: >> >>>> Works for me, thanks a lot Dan! >> >> >>>> Best Regards, >> >>>> Andriy Redko >> >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp wrote: >> >>>>>> I don't think anything blocking is left, +1 to move forward! @Colm >> >>>>>> @Dan >> >> >>>>> do >> >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? >> >>>>>> With >> >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the >> >>>>>> 3.4.x >> >>>>> is >> >>>>>> approaching EOL quickly, could be the last release. >> >>>>> I was definitely planning on doing 3.4/3.5 releases sometime before the >> >>>>> end of the year. Thus, we could do a full set of releases. I have a >> >>>>> bunch of things happening this week, but would next Monday work for >> >>>>> everyone? That would give a week to get any final updates in. >> >>>>> Dan >> >>>>>> Thank you guys! >> >>>>>> Best Regards, >> >>>>>>Andriy Redko >> >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma wrote: >> >>>>>>> Hi Andriy, >> >>>>>>> Can we start the release work if there isn't the major thing left we >> >>>>> need >> >>>>>>> to include in CXF 4.0.0 release ? >> >> >>>>>>> @Daniel Kulp Can you please help do the release >> >>>> when >> >>>>>>> it's convenient for you? >> >> >>>>>>> Thanks, >> >>>>>>> Jim >> >>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré >> >>>>>>> > >>>>>>> wrote: >> >> >>>>>>>> +1 to release 4.0.0 even partial release. >> >> >>>>>>>> Regards >> >>>>>>>> JB >> >>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma wrote: >> >>>>>>>>> Hi all, >> >>>>>>>>> After 9 months of work, we finally fixed/worked around all issues >> >>>> for >> >>>>>>>>> Jakarta support. Now all the cxf tests are passed: >> >>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can >> >>>>> say >> >>>>>>>> that >> >>>>>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta >> >> >>>>>>>> EE9.1). >> >>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF community >> >>>>>>>>> especially the user who asked for this jakarta artifacts like [1] >> >>>> and >> >>>>>>>> get >> >>>>>>>>> more feedback from our community, do you think it's time to release >> >>>>> the >> >>>>>>>> CXF >> >>>>>>>>> 4.0.0 and what else do you think we should have in this new jakarta >> >> >>>>>>>> release >> >>>>>>>>> ? >> >>>>>>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl >> >>>>>>>>> Thanks, >> >>>>>>>>> Jim >> >>>>> -- >> >>>>> Daniel Kulp >> >>>>> dk...@apache.org <mailto:dk...@apache.org> >> >>>>> Talend - https://talend.com <https://talend.com/> >>
Re: CXF 4.0.0 jakarta release
Hey guys, I have only these 3 issues to wrap up [1], [2], [3], for all of them pull requests are opened, waiting for minor changes / confirmations fixes work. @Dan @Colm appreciate your input on [4] please, this is to eliminate the leak of the REMOVED_MARKER. Thanks! [1] https://issues.apache.org/jira/browse/CXF-8798 [2] https://issues.apache.org/jira/browse/CXF-8799 [3] https://issues.apache.org/jira/browse/CXF-8796 [4] https://github.com/apache/cxf/pull/1033 Best Regards, Andriy Redko > I'm done now in terms of any remaining fixes for the next > releases...not sure if @Andriy Redko has anything else planned? > Colm. > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh > wrote: >> It works for me as well. I'm coordinating with @Andriy Redko on two >> fixes that remain for 3.5.x/3.4.x and then we should be good to go. >> Colm. >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma wrote: >>> Thanks Andriy and Dan ! >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko wrote: >>>> Works for me, thanks a lot Dan! >>>> Best Regards, >>>> Andriy Redko >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp wrote: >>>>>> I don't think anything blocking is left, +1 to move forward! @Colm @Dan >>>>> do >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x >>>>> is >>>>>> approaching EOL quickly, could be the last release. >>>>> I was definitely planning on doing 3.4/3.5 releases sometime before the >>>>> end of the year. Thus, we could do a full set of releases. I have a >>>>> bunch of things happening this week, but would next Monday work for >>>>> everyone? That would give a week to get any final updates in. >>>>> Dan >>>>>> Thank you guys! >>>>>> Best Regards, >>>>>>Andriy Redko >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma wrote: >>>>>>> Hi Andriy, >>>>>>> Can we start the release work if there isn't the major thing left we >>>>> need >>>>>>> to include in CXF 4.0.0 release ? >>>>>>> @Daniel Kulp Can you please help do the release >>>> when >>>>>>> it's convenient for you? >>>>>>> Thanks, >>>>>>> Jim >>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré >>>>>> wrote: >>>>>>>> +1 to release 4.0.0 even partial release. >>>>>>>> Regards >>>>>>>> JB >>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma wrote: >>>>>>>>> Hi all, >>>>>>>>> After 9 months of work, we finally fixed/worked around all issues >>>> for >>>>>>>>> Jakarta support. Now all the cxf tests are passed: >>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can >>>>> say >>>>>>>> that >>>>>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta >>>>>>>> EE9.1). >>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF community >>>>>>>>> especially the user who asked for this jakarta artifacts like [1] >>>> and >>>>>>>> get >>>>>>>>> more feedback from our community, do you think it's time to release >>>>> the >>>>>>>> CXF >>>>>>>>> 4.0.0 and what else do you think we should have in this new jakarta >>>>>>>> release >>>>>>>>> ? >>>>>>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl >>>>>>>>> Thanks, >>>>>>>>> Jim >>>>> -- >>>>> Daniel Kulp >>>>> dk...@apache.org <mailto:dk...@apache.org> >>>>> Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Regarding cxf-core split, correct, we won't be able to make it in 4.0.0 but dependencies should be formalized as optional [1] so we won't bring them in unless Spring 6 / Spring Boot 3 is on the picture. Thanks! [1] https://issues.apache.org/jira/browse/CXF-8791 Best Regards, Andriy Redko RMB> Hi, RMB> Ok so just to clarify it means RMB> 1. the cxf-core split (soap, rs, integration) is postponed > 4.x RMB> 2. the compiler setting is updated to add release (current setup is only RMB> source/target which does not guarantee that compiled with a jdk > version RMB> set in pom run on a lower jdk). RMB> Romain Manni-Bucau RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog RMB> <https://rmannibucau.metawerx.net/> | Old Blog RMB> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book RMB> <https://www.packtpub.com/application-development/java-ee-8-high-performance> RMB> Le mar. 8 nov. 2022 à 13:25, Jim Ma a écrit : >> Yes. Spring is optional for CXF runtime for a long time. Now all CXF >> binary classes/artifacts are all JDK-11 version (class major version >> 55) as Andriy >> mentioned >> we set target/source to JDK-11. I believe this setting on CXF at the >> moment is the best option: >> >>- Users don't need to upgrade the JDK version if they are using CXF >>without Spring. FWIK, there are a lot of non-Spring CXF users out >> there. >>- For the CXF Spring users, because the Spring 6 Jakarta version is >>JDK-17 baseline and built classes are JDK-17 versions(class major >> version >>61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17 is >>mandatory from Spring 6 and not from CXF. >> >> >> On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang >> wrote: >> >> > Hello, >> > >> > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring >> > optionally and we don't need to have spring artifacts on the classpath if >> > we don't want to use spring/spring boot features, and this has been the >> > case for a very long time. >> > >> > Freeman >> > >> > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau > > >> > wrote: >> > >> > > I was more referencing the long awaited split of cxf-core (it is still >> > the >> > > same old content than for the early jaxws time and without a modular >> > design >> > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this >> sounds >> > > like a big awaited features (don't start by bringing 1.4M said >> > otherwise). >> > > Since several part of OSGi dropped I think it would be good to create >> > > cxf-spring (and maybe spring-boot thanks some generator like camel). >> > > Since next release is mainly enabling cxf to hit jakarta, it sounds >> fine >> > > for me to drop spring if the refactor is too much and would delay a lot >> > the >> > > release - agree on this one. >> > > But keeping it like that means it will stay for years so likely that >> cxf >> > 4 >> > > will be the same than cxf 3 on this point which would be sad IMHO. >> > > >> > > Side note: indeed the obvious answer to that point is "v5" but it is >> > > pushing again this issue (coming from v2 ;)) and also makes the >> > versioning >> > > harder to follow if not pushed too far IMHO. >> > > >> > > Hope it makes sense. >> > > >> > > Romain Manni-Bucau >> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > > <https://rmannibucau.metawerx.net/> | Old Blog >> > > <http://rmannibucau.wordpress.com> | Github < >> > > https://github.com/rmannibucau> | >> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> > > < >> > > >> > >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > > > >> > > >> > > >> > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko a écrit : >> > > >> > > > Hi Romain, >> > > > >> > > > Thanks a lot for the feedback, just to clarify: we won't be dropping >> > > > Spring >> > > > (this is basically another "few months long" effort), it is merely to >> > try >> > > > to >> >
Re: CXF 4.0.0 jakarta release
Here we are [1], Dan has created 4.0.0 migration guide a while back, I filled it a bit. Thanks! [1] https://cwiki.apache.org/confluence/display/CXF20DOC/4.0+Migration+Guide Best Regards, Andriy Redko AR> Yes, I will create the page shortly and share on the list. AR> Best Regards, AR> Andriy Redko JM>> +1 to document this when we tag the release. There is a migration guide for JM>> each release like: https://cxf.apache.org/docs/35-migration-guide.html. JM>> Can we add this update in the 4.0 migration guide ? JM>> On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano wrote: >>> +1 >>> >>> I would suggest to deal with this in documentation, restricting runtime jdk >>> support to JDK17+ is actually going to create problems to some integration >>> (Spring is effectively optional already), while not really giving us much >>> (if you know you use Spring, just use JDK17, no need for it to be >>> mandatory). Btw, I believe JakartaEE 9.1 was meant to be used with JDK 8 or >>> 11; support for JDK 17 is something coming with JakartaEE 10 afair. >>> >>> Thanks >>> >>> On Tue, Nov 8, 2022 at 1:34 PM Jim Ma wrote: >>> >>> > Yes. Spring is optional for CXF runtime for a long time. Now all CXF >>> > binary classes/artifacts are all JDK-11 version (class major version >>> > 55) as Andriy >>> > mentioned >>> > we set target/source to JDK-11. I believe this setting on CXF at the >>> > moment is the best option: >>> > >>> >- Users don't need to upgrade the JDK version if they are using CXF >>> >without Spring. FWIK, there are a lot of non-Spring CXF users out >>> > there. >>> >- For the CXF Spring users, because the Spring 6 Jakarta version is >>> >JDK-17 baseline and built classes are JDK-17 versions(class major >>> > version >>> >61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17 >>> is >>> >mandatory from Spring 6 and not from CXF. >>> > >>> > >>> > On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang >>> > wrote: >>> > >>> > > Hello, >>> > > >>> > > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring >>> > > optionally and we don't need to have spring artifacts on the classpath >>> if >>> > > we don't want to use spring/spring boot features, and this has been the >>> > > case for a very long time. >>> > > >>> > > Freeman >>> > > >>> > > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau < >>> rmannibu...@gmail.com >>> > > >>> > > wrote: >>> > > >>> > > > I was more referencing the long awaited split of cxf-core (it is >>> still >>> > > the >>> > > > same old content than for the early jaxws time and without a modular >>> > > design >>> > > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this >>> > sounds >>> > > > like a big awaited features (don't start by bringing 1.4M said >>> > > otherwise). >>> > > > Since several part of OSGi dropped I think it would be good to create >>> > > > cxf-spring (and maybe spring-boot thanks some generator like camel). >>> > > > Since next release is mainly enabling cxf to hit jakarta, it sounds >>> > fine >>> > > > for me to drop spring if the refactor is too much and would delay a >>> lot >>> > > the >>> > > > release - agree on this one. >>> > > > But keeping it like that means it will stay for years so likely that >>> > cxf >>> > > 4 >>> > > > will be the same than cxf 3 on this point which would be sad IMHO. >>> > > > >>> > > > Side note: indeed the obvious answer to that point is "v5" but it is >>> > > > pushing again this issue (coming from v2 ;)) and also makes the >>> > > versioning >>> > > > harder to follow if not pushed too far IMHO. >>> > > > >>> > > > Hope it makes sense. >>> > > > >>> > > > Romain Manni-Bucau >>> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> > > > <https://rmannibucau.metawerx.net/> | O
Re: CXF 4.0.0 jakarta release
Hi Jim, I am not aware of any but @Colm is the source of truth here :-) Thanks! Best Regards, Andriy Redko > We can probably include this upgrade in the CXF 4.1 or later version after > it's released and get into WSS4j. > AFAIK, there is no CXF or WSS4j issue blocked by the OpenSAML 5.0.0 upgrade. > @Colm O hEigeartaigh @Andriy Redko WDYT ? > On Mon, Nov 7, 2022 at 9:25 PM Misagh wrote: >> Hello all, >> If possible, I'd like to ask that you allow v4 to ship with a new >> release of wss4j that would contain this change: >> https://github.com/apache/ws-wss4j/pull/62 >> At the moment, OpenSAML v5 is not released yet, but it is anticipated >> to be GA before end of this year, hopefully. >> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma wrote: >>> >>> Hi all, >>> After 9 months of work, we finally fixed/worked around all issues for >>> Jakarta support. Now all the cxf tests are passed: >>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say that >>> CXF successfully migrated to Jakarta namespace(and support Jakarta EE9.1). >>> To get cxf jakarta artifacts/binary available for the CXF community >>> especially the user who asked for this jakarta artifacts like [1] and get >>> more feedback from our community, do you think it's time to release the CXF >>> 4.0.0 and what else do you think we should have in this new jakarta release >>> ? >>> >>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl >>> >>> Thanks, >>> Jim
Re: CXF 4.0.0 jakarta release
Yes, I will create the page shortly and share on the list. Best Regards, Andriy Redko JM> +1 to document this when we tag the release. There is a migration guide for JM> each release like: https://cxf.apache.org/docs/35-migration-guide.html. JM> Can we add this update in the 4.0 migration guide ? JM> On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano wrote: >> +1 >> >> I would suggest to deal with this in documentation, restricting runtime jdk >> support to JDK17+ is actually going to create problems to some integration >> (Spring is effectively optional already), while not really giving us much >> (if you know you use Spring, just use JDK17, no need for it to be >> mandatory). Btw, I believe JakartaEE 9.1 was meant to be used with JDK 8 or >> 11; support for JDK 17 is something coming with JakartaEE 10 afair. >> >> Thanks >> >> On Tue, Nov 8, 2022 at 1:34 PM Jim Ma wrote: >> >> > Yes. Spring is optional for CXF runtime for a long time. Now all CXF >> > binary classes/artifacts are all JDK-11 version (class major version >> > 55) as Andriy >> > mentioned >> > we set target/source to JDK-11. I believe this setting on CXF at the >> > moment is the best option: >> > >> >- Users don't need to upgrade the JDK version if they are using CXF >> >without Spring. FWIK, there are a lot of non-Spring CXF users out >> > there. >> >- For the CXF Spring users, because the Spring 6 Jakarta version is >> >JDK-17 baseline and built classes are JDK-17 versions(class major >> > version >> >61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17 >> is >> >mandatory from Spring 6 and not from CXF. >> > >> > >> > On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang >> > wrote: >> > >> > > Hello, >> > > >> > > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring >> > > optionally and we don't need to have spring artifacts on the classpath >> if >> > > we don't want to use spring/spring boot features, and this has been the >> > > case for a very long time. >> > > >> > > Freeman >> > > >> > > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau < >> rmannibu...@gmail.com >> > > >> > > wrote: >> > > >> > > > I was more referencing the long awaited split of cxf-core (it is >> still >> > > the >> > > > same old content than for the early jaxws time and without a modular >> > > design >> > > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this >> > sounds >> > > > like a big awaited features (don't start by bringing 1.4M said >> > > otherwise). >> > > > Since several part of OSGi dropped I think it would be good to create >> > > > cxf-spring (and maybe spring-boot thanks some generator like camel). >> > > > Since next release is mainly enabling cxf to hit jakarta, it sounds >> > fine >> > > > for me to drop spring if the refactor is too much and would delay a >> lot >> > > the >> > > > release - agree on this one. >> > > > But keeping it like that means it will stay for years so likely that >> > cxf >> > > 4 >> > > > will be the same than cxf 3 on this point which would be sad IMHO. >> > > > >> > > > Side note: indeed the obvious answer to that point is "v5" but it is >> > > > pushing again this issue (coming from v2 ;)) and also makes the >> > > versioning >> > > > harder to follow if not pushed too far IMHO. >> > > > >> > > > Hope it makes sense. >> > > > >> > > > Romain Manni-Bucau >> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > > > <https://rmannibucau.metawerx.net/> | Old Blog >> > > > <http://rmannibucau.wordpress.com> | Github < >> > > > https://github.com/rmannibucau> | >> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> > > > < >> > > > >> > > >> > >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > > > > >> > > > >> > > > >> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko a >> écrit : >> > >
Re: [VOTE] - Move Apache CXF DOSGi to the attic
+1, thanks Colm! Best Regards, Andriy Redko COh> This is a vote to move Apache CXF DOSGi to the attic. There is very COh> little activity for many years now (last commit 2.5 years ago - COh> https://github.com/apache/cxf-dosgi/commits/main). COh> Previous discussion thread: COh> https://lists.apache.org/thread/tjq9058n161p7fk8137nonwlfqvm9gys COh> +1 from me. COh> Colm.
Re: CXF 4.0.0 jakarta release
Hi Romain, Thanks a lot for the feedback, just to clarify: we won't be dropping Spring (this is basically another "few months long" effort), it is merely to try to not bring any dependency with JDK-17 baseline (== Spring / Spring Boot at this moment) by default. It would definitely require more work for the users to wire everything properly but at least that would allow us to preserve JDK-11 baseline. Apologies if I am rephrasing what you intended to say, just an attempt to eliminate the possible confusion. Thank you. > Think Java 11 is a good baseline as of today - at least to enable Jakarta > vendors to use CXF as an implementation and pass tck. > +1 to drop spring if it bothers to get a first 4.0.0 release out, we can > catch up later like other dropped integrations and core should be exploded > anyway, it is way too fat for what it does so moving spring out of it is > quite a good direction IMHO. > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > Le lun. 7 nov. 2022 à 18:06, Freeman Fang a écrit : >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline since we >> upgraded to Spring 6 and Spring Boot 3. >> Thanks to all guys involved in this long process! >> Freeman >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko wrote: >>> +1 to move forward with release (or milestone), but before that, there is >>> one issue which >>> I would like to bring up and agree us upon. The initial discussion for >>> Jakarta / 4.0.0 [1] concluded >>> on having JDK-11 as a baseline. At the same time, there is a misalignment >>> with Spring 6 / Spring Boot 3 >>> requirements which bumped the baseline to JDK-17. Now, the way we build >>> Jakarta / 4.0.0 branch (main) is >>> like this: use JDK-17+ but set target/source to JDK-11. >>> With that being said, the not so good part. Technically, Jakarta / 4.0.0 >>> bits could be used in the >>> projects which are still using JDK-11. But because mostly every single >>> piece (starting from cxf-core) depends >>> on Spring, the application fail to start with >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm >>> on any CXF provided sample). Effectively, the baseline is JDK-17, not >>> JDK-11 (we have hoped to isolate Spring >>> related implementation but it hasn't happened yet and not sure it will in >>> the future). The question: does >>> anyone have a compelling usecase for keeping CXF baseline at JDK-11 level >>> despite being able to run only >>> on JDK-17 or above? If yes, I think we have to make all Spring related >>> dependencies optional and document >>> clearly that JDK-17 is needed in case Spring / Spring Boot are used, we >>> surely cannot leave things >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a >>> baseline. >>> What do you guys think? >>> Thank you. >>> [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html >>> Best Regards, >>> Andriy Redko >>> Monday, November 7, 2022, 8:50:02 AM, you wrote: RMB>>>> +1 to release, there are too much forks out there already so better >> to RMB>>>> release partially than not release at all IMHO RMB>>>> Romain Manni-Bucau RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog RMB>>>> <http://rmannibucau.wordpress.com> | Github < >>> https://github.com/rmannibucau> | RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book RMB>>>> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh a >>> écrit : >>>>> Hello all, >>>>> If possible, I'd like to ask that you allow v4 to ship with a new >>>>> release of wss4j that would contain this change: >>>>> https://github.com/apache/ws-wss4j/pull/62 >>>>> At the moment, OpenSAML v5 is not released yet, but it is anticipated >>>>> to be GA before end of this year, hopefully. >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma wrote: >>>>>> Hi all, >>>>>> After 9 mo
Re: CXF 4.0.0 jakarta release
+1 to move forward with release (or milestone), but before that, there is one
issue which
I would like to bring up and agree us upon. The initial discussion for Jakarta
/ 4.0.0 [1] concluded
on having JDK-11 as a baseline. At the same time, there is a misalignment with
Spring 6 / Spring Boot 3
requirements which bumped the baseline to JDK-17. Now, the way we build Jakarta
/ 4.0.0 branch (main) is
like this: use JDK-17+ but set target/source to JDK-11.
With that being said, the not so good part. Technically, Jakarta / 4.0.0 bits
could be used in the
projects which are still using JDK-11. But because mostly every single piece
(starting from cxf-core) depends
on Spring, the application fail to start with
"java.lang.UnsupportedClassVersionError" (very easy to confirm
on any CXF provided sample). Effectively, the baseline is JDK-17, not JDK-11
(we have hoped to isolate Spring
related implementation but it hasn't happened yet and not sure it will in the
future). The question: does
anyone have a compelling usecase for keeping CXF baseline at JDK-11 level
despite being able to run only
on JDK-17 or above? If yes, I think we have to make all Spring related
dependencies optional and document
clearly that JDK-17 is needed in case Spring / Spring Boot are used, we surely
cannot leave things
as-is (in my opinion). If not, I would suggest to set JDK-17 as a baseline.
What do you guys think?
Thank you.
[1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
Best Regards,
Andriy Redko
Monday, November 7, 2022, 8:50:02 AM, you wrote:
RMB> +1 to release, there are too much forks out there already so better to
RMB> release partially than not release at all IMHO
RMB> Romain Manni-Bucau
RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB> <https://rmannibucau.metawerx.net/> | Old Blog
RMB> <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> |
RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
RMB>
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
RMB> Le lun. 7 nov. 2022 à 14:25, Misagh a écrit :
>> Hello all,
>>
>> If possible, I'd like to ask that you allow v4 to ship with a new
>> release of wss4j that would contain this change:
>> https://github.com/apache/ws-wss4j/pull/62
>>
>> At the moment, OpenSAML v5 is not released yet, but it is anticipated
>> to be GA before end of this year, hopefully.
>>
>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma wrote:
>> >
>> > Hi all,
>> > After 9 months of work, we finally fixed/worked around all issues for
>> > Jakarta support. Now all the cxf tests are passed:
>> > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say
>> that
>> > CXF successfully migrated to Jakarta namespace(and support Jakarta
>> EE9.1).
>> > To get cxf jakarta artifacts/binary available for the CXF community
>> > especially the user who asked for this jakarta artifacts like [1] and
>> get
>> > more feedback from our community, do you think it's time to release the
>> CXF
>> > 4.0.0 and what else do you think we should have in this new jakarta
>> release
>> > ?
>> >
>> > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>> >
>> > Thanks,
>> > Jim
>>
Re: Reg: REST API documentation for cxf-2.4.6 version
Hello Tanuja, Yes, you could use WADL [1], if you would like to auto-generate WADL, please check [2]. Thank you. [1] https://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-WADL [2] https://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-WADLAutoGenerationatRuntime Best Regards, Andriy Redko > Thank you for your response, Andriy. > This is an existing application and I am bound by certain limitations which > include not being able to upgrade to any newer version. > This is a POC that I am trying to develop on my own and not a requirement > from the higher ups. Yet, giving my best shot. > How about generating WADL? Postman tool can still import WADL files and this > solves at least half the purpose. > And there are WADL to Swagger conversion tools as well. This would be my next > step in the process provided a WADL file can be generated with Apache CXF > 2.4.6 > There are @Descriptions and @Description annotations available and I have > annotated one of the existing REST classes and methods appropriately. But, > how is the WADL file generated? Do I have to follow any steps to create one? > If yes, pls mention those. > I am referring to the following links. > https://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-WADL > https://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-DocumentingresourceclassesandmethodsingeneratedWADL > On Mon, Oct 24, 2022 at 6:25 AM Andriy Redko wrote: >> Hello Tanuja, >> The SwaggerFeature was introduced in Apache CXF 3.0 [1], but as far as I >> understand, you are trying to use Apache CXF 2.4.6 and pulling the >> cxf-rt-rs-service-description-3.0.0.jar with it. If that is the case, >> it is not going to work out. The recommendation would be to update to >> one of the supported Apache CXF releases [2]. >> Thank you. >> [1] https://issues.apache.org/jira/browse/CXF-5379 >> [2] https://cxf.apache.org/download.html >> Best Regards, >> Andriy Redko TS>>> Hello everyone, TS>>> My project uses cxf-2.4.6 version. There is no REST API documentation as of TS>>> date. TS>>> I plan to create one and have been exploring various options for this TS>>> version. TS>>> Official documentation mentions that SwaggerFeature needs to be used for TS>>> this version. TS>>> https://cwiki.apache.org/confluence/display/CXF20DOC/Swagger2Feature TS>>> As per the above link, TS>>> *For generating Swagger 1.2 TS>>> <https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md> TS>>> documents, TS>>> you can use SwaggerFeature instead of Swagger2Feature (for CXF versions <= TS>>> 3.1.x).* TS>>> But, I am lost here. TS>>> Added all the needed jars. Ant is used as a build tool; hence, individual TS>>> jars are added manually. TS>>> scala-library-2.7.7.jar TS>>> swagger-jaxrs_2.10-1.3.13.jar TS>>> swagger-ui-2.1.2.jar TS>>> swagger-annotations-1.5.2.jar TS>>> swagger-jaxrs-1.5.2.jar TS>>> cxf-rt-rs-service-description-3.0.0.jar TS>>> I've added this bean in the cxfbeans.xml. TS>>> TS>>> >> class="org.apache.cxf.jaxrs.swagger.SwaggerFeature"> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> TS>>> Now, server doesn't start and I get this exception. TS>>> org.springframework.beans.factory.BeanCreationException: Error creating TS>>> bean with name ' testServiceId': Invocation of init method failed; nested TS>>> exception is org.apache.cxf.service.factory.ServiceConstructionException TS>>> at TS>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338) TS>>> at TS>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) TS>>> at TS>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) TS>>> at java.security.AccessController.doPrivileged(Native Method) TS>>> at TS>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapabl
Re: Reg: REST API documentation for cxf-2.4.6 version
Hello Tanuja, The SwaggerFeature was introduced in Apache CXF 3.0 [1], but as far as I understand, you are trying to use Apache CXF 2.4.6 and pulling the cxf-rt-rs-service-description-3.0.0.jar with it. If that is the case, it is not going to work out. The recommendation would be to update to one of the supported Apache CXF releases [2]. Thank you. [1] https://issues.apache.org/jira/browse/CXF-5379 [2] https://cxf.apache.org/download.html Best Regards, Andriy Redko TS> Hello everyone, TS> My project uses cxf-2.4.6 version. There is no REST API documentation as of TS> date. TS> I plan to create one and have been exploring various options for this TS> version. TS> Official documentation mentions that SwaggerFeature needs to be used for TS> this version. TS> https://cwiki.apache.org/confluence/display/CXF20DOC/Swagger2Feature TS> As per the above link, TS> *For generating Swagger 1.2 TS> <https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md> TS> documents, TS> you can use SwaggerFeature instead of Swagger2Feature (for CXF versions <= TS> 3.1.x).* TS> But, I am lost here. TS> Added all the needed jars. Ant is used as a build tool; hence, individual TS> jars are added manually. TS> scala-library-2.7.7.jar TS> swagger-jaxrs_2.10-1.3.13.jar TS> swagger-ui-2.1.2.jar TS> swagger-annotations-1.5.2.jar TS> swagger-jaxrs-1.5.2.jar TS> cxf-rt-rs-service-description-3.0.0.jar TS> I've added this bean in the cxfbeans.xml. TS> TS> class="org.apache.cxf.jaxrs.swagger.SwaggerFeature"> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> TS> Now, server doesn't start and I get this exception. TS> org.springframework.beans.factory.BeanCreationException: Error creating TS> bean with name ' testServiceId': Invocation of init method failed; nested TS> exception is org.apache.cxf.service.factory.ServiceConstructionException TS> at TS> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338) TS> at TS> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) TS> at TS> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) TS> at java.security.AccessController.doPrivileged(Native Method) TS> at TS> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) TS> at TS> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) TS> at TS> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) TS> at TS> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) TS> at TS> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) TS> at TS> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164) TS> at TS> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429) TS> at TS> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728) TS> at TS> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380) TS> at TS> org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255) TS> at TS> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) TS> at TS> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) TS> at TS> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4727) TS> at TS> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5189) TS> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) TS> at TS> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1403) TS> at TS> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393) TS> at java.util.concurrent.FutureTask.run(FutureTask.java:266) TS> at TS> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) TS> at TS> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617
Re: [DISCUSS] - Retire CXF DOSGI?
Hi Colm, I have never seen it used in the wild (at least, the projects I was/am involved with), I think it would make sense to retire it, especially taking into account the OSGi vague plans to support Jakarta. +1 from my side to move it to the attic. Thank you. Best Regards, Andriy Redko COh> Hi all, COh> What do you think about moving CXF DOSGI to the attic? There is very COh> little activity for many years now (last commit 2.5 years ago - COh> https://github.com/apache/cxf-dosgi/commits/main). It's just a COh> maintenance burden unless someone steps up to maintain it properly. COh> Colm.
WSS4J 3.0.0 update and cxf-rt-ws-security tests
Hey Colm, Interesting side effect after updating main to WSS4J 3.0.0: the cxf-rt-ws-security tests are started to take very long time (not all, but some, for example DOMToStaxEncryptionIdentifierTest, 930.104 s): [INFO] Running org.apache.cxf.ws.security.wss4j.DOMToStaxEncryptionIdentifierTest [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 930.104 s - in org.apache.cxf.ws.security.wss4j.DOMToStaxEncryptionIdentifierTest The builds are aborted right now [1] because of long time of inactivity. If you have time to look at it, would be great, I will try to find out what is going on as well. Thank you. [1] https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ Best Regards, Andriy Redko
Re: [DISCUSS] CXF 3.5.x and beyond
Thanks David. I think the most efficient way for CXF team is to focus on 4.0.0. We have a few blockers along the way which we are working on. To put it in perspective, there are modules which are excluded from the builds at the moment, no equivalent replacement of the dependencies in Jakarta space, but eventually those should be there. In any case, I think the way to approach the contrubutions to 4.1 could be to create the pull request against main (for now), once 4.0.0 is branched off, it could be merged. It may not the most convenient for you, but would help us to focus on 4.0.0 only. What do you think? Thank you. Best Regards, Andriy Redko >> On Oct 8, 2022, at 8:21 PM, Andriy Redko wrote: >> >> I was thinking about that as well, since Jakarta EE 10 is already out [1]. >> If I am not mistaken, >> we haven't discussed the future Jakarta plans yet, trying to address major >> 4.0.0 migration issues. >> Personally I was thinking that having 4.1.x release dedicated to Jakarta EE >> 10 is probably way to >> go (and consequently following this branching strategy for the future >> Jakarta EE releases like >> 4.2.x, 4.3.x, ...). I am curious what others think about that. DB> That sounds like a good plan to me. DB> I know on the TomEE side the community seems to be anxious to get 9 out the door so work on 10 can start. Likely that means 9 will immediately get branched and go into maintenance mode, which is a bit different to what we'd normally do. Usually the next version doesn't really start for quite a few months. DB> Do we think we might be willing to accept contributions on a potential 4.1 pretty soon after 4.0 goes final or would there be some desire to let 4.0.0 mature for a few months before starting a potential 4.1? DB> -David
Re: [DISCUSS] CXF 3.5.x and beyond
Hey David, I was thinking about that as well, since Jakarta EE 10 is already out [1]. If I am not mistaken, we haven't discussed the future Jakarta plans yet, trying to address major 4.0.0 migration issues. Personally I was thinking that having 4.1.x release dedicated to Jakarta EE 10 is probably way to go (and consequently following this branching strategy for the future Jakarta EE releases like 4.2.x, 4.3.x, ...). I am curious what others think about that. Last but not least, your understanding of the current state of 4.0.0 is correct. Thank you. [1] https://jakarta.ee/release/10/ Best Regards, Andriy Redko DB> Jumping into a random spot in this thread. DB> My understanding of the current state of 4.0.0 is: DB> - Targets Java 17 due to Spring deps DB> - Targets Jakarta EE 9 / Jakarta Rest 3.0 DB> The trick for us on the TomEE side is that Jakarta EE 9.1 requires support for Java 11. We're still using 3.5.x with bytecode transformation, which is fine for TomEE 9. It's nearly done. DB> Our first opportunity to set Java 17 as the base is Jakarta EE 10. The trick for us there is we'd need Jakarta Rest 3.1. DB> We're hoping to get TomEE 9 out the door this year and once that is done we'd be turning our attention to TomEE 10, which is primarily going to involve contributing to the projects we need. My question, is where would contributions to Jakarta Rest 3.1 be welcome? DB> Is there some willingness to go straight to Jakarta Rest 3.1 in CXF 4.0.0 if help showed up or would we want that in a separate branch? (4.1.x or 5.x?) DB> Thoughts? DB> -David >> On Sep 29, 2022, at 7:03 PM, Andriy Redko wrote: >> >> Hey Colm, >> >> All skipped projects are listed here [1], the test cases (for now) don't >> have JIRAs >> but will be fixed at some point (hopefully - very soon), I am not sure we >> need separate >> tickets for that since we don't silence/ignore them. Thanks! >> >> [1] https://issues.apache.org/jira/browse/CXF-8724 >> >> Best Regards, >>Andriy Redko >> >> COh> Hi, >> >> COh> No objection from me either. Apart from OSGi, could we make sure that >> COh> all the gaps are recorded in JIRA? >> >> COh> * Test failures in cxf-rt-mp-client - >> COh> https://issues.apache.org/jira/browse/CXF-8758 >> COh> * Test failures in >> COh> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket >> COh> related) - https://issues.apache.org/jira/browse/CXF-8717 >> COh> * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is >> COh> failing in the jms transport systests - JIRA? >> COh> * ./systests/container-integration/grizzly skipped - >> COh> https://issues.apache.org/jira/browse/CXF-8716 >> COh> * jaxrs systests skipped - JIRA? >> COh> * systests/wsdl_maven/codegen skipped - JIRA? >> COh> * maven-plugins/wadl2java-plugin - JIRA? >> COh> * maven-plugins/java2swagger-plugin - JIRA? >> >> COh> Colm. >> >> COh> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko wrote: >>>> >>>> Hi Jim, >>>> >>>> No objections from my side, thank you. >>>> >>>> Best Regards, >>>>Andriy Redko >>>> >>>> On Tue, Sep 27, 2022, 9:31 PM Jim Ma wrote: >>>>> >>>>> Hi all, >>>>> If there is no objection, I will create a branch "osgi-pre-removal-v4.0" >>>>> to record the changes before the osgi and karaf removal, then >>>>> merge the this PR https://github.com/apache/cxf/pull/999 to the main >>>>> branch. >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> On Thu, Sep 22, 2022 at 9:06 PM Andrey Redko wrote: >>>>>> >>>>>> This is great, thanks Jim, I will also take a look shortly. Thanks! >>>>>> >>>>>> Best Regards, >>>>>>Andriy Redko >>>>>> >>>>>> On Wed, Sep 21, 2022, 1:02 AM Jim Ma wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> I tried to remove the osgi and karaf from CXF with this draft PR : >>>>>>> https://github.com/apache/cxf/pull/999. >>>>>>> This mainly removed the osgi code,test, examples and dependency, but >>>>>>> for some class like SpringBus which deeply coupled with osgi: >>>>>>> https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142 >>>>&
Re: Please update 4.0-SNAPSHOT
Hey guys, The first 4.0.0-SNAPSHOTs are available now [1], some modules are still not there [2] but will be added as we move ahead. Please notice that JDK-17 is a minimal required JDK version (due to Spring Framework 6 baseline). Thank you. [1] https://ci-builds.apache.org/job/CXF/job/CXF-JDK17-deploy/79/ [2] https://issues.apache.org/jira/browse/CXF-8724 Best Regards, Andriy Redko > Hi Andriy, > I think you are close, the errors are just Javadoc-related for Swagger and > Jetty 9. Great work so far, really unfortunate that I didn't found the time > to contribute... > Best, > Dennis
Re: [VOTE] Apache CXF 3.4.9 and 3.5.4
+1, thanks a lot Dan! Best Regards, Andriy Redko DK> This is a vote to release the latest set of patched for CXF. DK> Staging repository: (I forgot to close the repo between builds so only a single staging repository that has both versions) DK> https://repository.apache.org/content/repositories/orgapachecxf-1182/ DK> Tags: DK> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=0f3e02bf6a402c76c2fb66469df53b583e0fc9a4 DK> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=1a49835461a0b4f56d53ad513a7665a72025c736 DK> Here is my +1
Re: [DISCUSS] CXF 3.5.x and beyond
Hey Colm, All skipped projects are listed here [1], the test cases (for now) don't have JIRAs but will be fixed at some point (hopefully - very soon), I am not sure we need separate tickets for that since we don't silence/ignore them. Thanks! [1] https://issues.apache.org/jira/browse/CXF-8724 Best Regards, Andriy Redko COh> Hi, COh> No objection from me either. Apart from OSGi, could we make sure that COh> all the gaps are recorded in JIRA? COh> * Test failures in cxf-rt-mp-client - COh> https://issues.apache.org/jira/browse/CXF-8758 COh> * Test failures in COh> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket COh> related) - https://issues.apache.org/jira/browse/CXF-8717 COh> * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is COh> failing in the jms transport systests - JIRA? COh> * ./systests/container-integration/grizzly skipped - COh> https://issues.apache.org/jira/browse/CXF-8716 COh> * jaxrs systests skipped - JIRA? COh> * systests/wsdl_maven/codegen skipped - JIRA? COh> * maven-plugins/wadl2java-plugin - JIRA? COh> * maven-plugins/java2swagger-plugin - JIRA? COh> Colm. COh> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko wrote: >> >> Hi Jim, >> >> No objections from my side, thank you. >> >> Best Regards, >> Andriy Redko >> >> On Tue, Sep 27, 2022, 9:31 PM Jim Ma wrote: >>> >>> Hi all, >>> If there is no objection, I will create a branch "osgi-pre-removal-v4.0" to >>> record the changes before the osgi and karaf removal, then >>> merge the this PR https://github.com/apache/cxf/pull/999 to the main branch. >>> >>> Thanks, >>> Jim >>> >>> On Thu, Sep 22, 2022 at 9:06 PM Andrey Redko wrote: >>>> >>>> This is great, thanks Jim, I will also take a look shortly. Thanks! >>>> >>>> Best Regards, >>>> Andriy Redko >>>> >>>> On Wed, Sep 21, 2022, 1:02 AM Jim Ma wrote: >>>>> >>>>> Hi All, >>>>> I tried to remove the osgi and karaf from CXF with this draft PR : >>>>> https://github.com/apache/cxf/pull/999. >>>>> This mainly removed the osgi code,test, examples and dependency, but for >>>>> some class like SpringBus which deeply coupled with osgi: >>>>> https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142 >>>>> I added the comment "//uncomment this when osgi comes back" to mark these >>>>> commented lines for osgi. With the branch created before >>>>> this change is merged to main, I am sure this will make it easy to bring >>>>> the osgi and karaf back when the Jakarta support is ready in the future. >>>>> >>>>> Please help review this PR. If you have any comment or question, please >>>>> let me know. >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> >>>>> On Sat, Sep 10, 2022 at 4:05 AM Andriy Redko wrote: >>>>>> >>>>>> Hi Jim, >>>>>> >>>>>> That is correct, I am working on >>>>>> https://issues.apache.org/jira/browse/CXF-8717 as part of >>>>>> Jetty 11 migration, the Atmosphere implementation seems to be fine. >>>>>> Thanks. >>>>>> >>>>>> Best Regards, >>>>>> Andriy Redko >>>>>> >>>>>> >>>>>> JM> Thanks for the update, Andiry. You already did a lot of work on >>>>>> third party >>>>>> JM> jakarta support ! >>>>>> >>>>>> JM> Just to understand the CXF Jakarta support work status, are these >>>>>> issues we >>>>>> JM> can start without waiting for the dependency release ? >>>>>> JM> https://issues.apache.org/jira/browse/CXF-8716 >>>>>> JM> https://issues.apache.org/jira/browse/CXF-8717 >>>>>> JM> https://issues.apache.org/jira/browse/CXF-8719 >>>>>> >>>>>> >>>>>> >>>>>> JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko wrote: >>>>>> >>>>>> >> Hi Jim, >>>>>> >> >>>>>> >> Yeah, we may need some time, I am also finalizing work on the >>>>>> >> Wiremock ( >>>>>> >>
Re: [DISCUSS] CXF 3.5.x and beyond
Hey Jim, Yes, the maven-plugins/wadl2java-plugin is blocked by [1], no Jakarta release. Thanks! [1] https://github.com/highsource/jaxb2-basics Best Regards, Andriy Redko JM> I already created a branch for the pre-removal and merged this osgi removal JM> change to the main branch . JM> For these test failures and skipped modules, I'll have a look and fill a JM> JIRA for them after I resolve the JM> grizzly jakarta upgrade : https://issues.apache.org/jira/browse/CXF-8716. JM> @Andriy Redko Do you remember why we skipped the JM> maven-plugins/wadl2java-plugin and systests/wsdl_maven/codegen ? JM> I remembered we analyzed this before , but I can't find the discussion log. JM> On Wed, Sep 28, 2022 at 4:30 PM Colm O hEigeartaigh JM> wrote: >> Hi, >> >> No objection from me either. Apart from OSGi, could we make sure that >> all the gaps are recorded in JIRA? >> >> * Test failures in cxf-rt-mp-client - >> https://issues.apache.org/jira/browse/CXF-8758 >> * Test failures in >> cxf-systests-transports-undertow,cxf-systests-jaxws (websocket >> related) - https://issues.apache.org/jira/browse/CXF-8717 >> * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is >> failing in the jms transport systests - JIRA? >> * ./systests/container-integration/grizzly skipped - >> https://issues.apache.org/jira/browse/CXF-8716 >> * jaxrs systests skipped - JIRA? >> * systests/wsdl_maven/codegen skipped - JIRA? >> * maven-plugins/wadl2java-plugin - JIRA? >> * maven-plugins/java2swagger-plugin - JIRA? >> >> Colm. >> >> On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko wrote: >> > >> > Hi Jim, >> > >> > No objections from my side, thank you. >> > >> > Best Regards, >> > Andriy Redko >> > >> > On Tue, Sep 27, 2022, 9:31 PM Jim Ma wrote: >> >> >> >> Hi all, >> >> If there is no objection, I will create a branch >> "osgi-pre-removal-v4.0" to record the changes before the osgi and karaf >> removal, then >> >> merge the this PR https://github.com/apache/cxf/pull/999 to the main >> branch. >> >> >> >> Thanks, >> >> Jim >> >> >> >> On Thu, Sep 22, 2022 at 9:06 PM Andrey Redko wrote: >> >>> >> >>> This is great, thanks Jim, I will also take a look shortly. Thanks! >> >>> >> >>> Best Regards, >> >>> Andriy Redko >> >>> >> >>> On Wed, Sep 21, 2022, 1:02 AM Jim Ma wrote: >> >>>> >> >>>> Hi All, >> >>>> I tried to remove the osgi and karaf from CXF with this draft PR : >> https://github.com/apache/cxf/pull/999. >> >>>> This mainly removed the osgi code,test, examples and dependency, but >> for some class like SpringBus which deeply coupled with osgi: >> >>>> >> https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142 >> >>>> I added the comment "//uncomment this when osgi comes back" to mark >> these commented lines for osgi. With the branch created before >> >>>> this change is merged to main, I am sure this will make it easy to >> bring the osgi and karaf back when the Jakarta support is ready in the >> future. >> >>>> >> >>>> Please help review this PR. If you have any comment or question, >> please let me know. >> >>>> >> >>>> Thanks, >> >>>> Jim >> >>>> >> >>>> >> >>>> On Sat, Sep 10, 2022 at 4:05 AM Andriy Redko >> wrote: >> >>>>> >> >>>>> Hi Jim, >> >>>>> >> >>>>> That is correct, I am working on >> https://issues.apache.org/jira/browse/CXF-8717 as part of >> >>>>> Jetty 11 migration, the Atmosphere implementation seems to be fine. >> Thanks. >> >>>>> >> >>>>> Best Regards, >> >>>>> Andriy Redko >> >>>>> >> >>>>> >> >>>>> JM> Thanks for the update, Andiry. You already did a lot of work on >> third party >> >>>>> JM> jakarta support ! >> >>>>> >> >>>>> JM> Just to understand the CXF Jakarta support work status, are >> these issues we >> >>>>> JM> can start without waiting for the depend
Re: [RELEASE REQUEST] Next 3.x release?
Hey Colm, All set from my side, sorry about that, we should be good to go with 3.5.x / 3.4.x releases. Thank you. Best Regards, Andriy Redko COh> Hi @Andriy Redko , COh> We're overdue on these releases, do you think we could get the fixes COh> done soon or bump them to the next release? COh> Thanks, COh> Colm. COh> On Tue, Aug 23, 2022 at 6:36 AM Andriy Redko wrote: >> >> Hi Romain, >> >> I think it is feasible to have a release in a few weeks (if there are >> no objections from the guys), from my side I have to wrap up one MTOM >> regression and one more issue related to MTOM content injection. >> Thanks. >> >> Best Regards, >> Andriy Redko >> >> >> RMB> Hi all, >> >> RMB> Is it possible to get a 3.5.4 or 3.6 out to be able to get back >> RMB> https://issues.apache.org/jira/browse/CXF-8732 please ? >> >> RMB> Thanks, >> RMB> Romain Manni-Bucau >> RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> RMB> <https://rmannibucau.metawerx.net/> | Old Blog >> RMB> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | >> RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> RMB> >> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>
Re: Please update 4.0-SNAPSHOT
Hey guys, The 4.0.0 is not yet in the buildable and publishable state but we are getting there. Thank you. Best Regards, Andriy Redko > Hi Vladimir, > the reason for that is that the build is failing since then: > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17-deploy/ > Will take a look... > Dennis
Re: [DISCUSS] CXF 3.5.x and beyond
Hi Jim, That is correct, I am working on https://issues.apache.org/jira/browse/CXF-8717 as part of Jetty 11 migration, the Atmosphere implementation seems to be fine. Thanks. Best Regards, Andriy Redko JM> Thanks for the update, Andiry. You already did a lot of work on third party JM> jakarta support ! JM> Just to understand the CXF Jakarta support work status, are these issues we JM> can start without waiting for the dependency release ? JM> https://issues.apache.org/jira/browse/CXF-8716 JM> https://issues.apache.org/jira/browse/CXF-8717 JM> https://issues.apache.org/jira/browse/CXF-8719 JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko wrote: >> Hi Jim, >> >> Yeah, we may need some time, I am also finalizing work on the Wiremock ( >> https://github.com/wiremock/wiremock/pull/1942), >> we use it in tests extensively. One of the largest efforts is migration to >> Jetty 11, I have started on that already but >> have difficulties with WebSockets migration, it needs rework and that is >> my focus at the moment. The Swagger 1.x we have >> to drop I believe, I don't see roadmap on Jakarta support there. >> >> Thanks! >> >> Best Regards, >> Andriy Redko >> >> JM> Hi Andriy, >> JM> It looks like we still have to wait for the other dependency jakarta >> JM> support available, like brave's new release to include this change : >> JM> https://github.com/openzipkin/brave/pull/1344. Do you see any other >> JM> dependencies that haven't been released yet except OSGI and Karaf ? >> >> JM> Thanks, >> JM> Jim >> >> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma wrote: >> >> >> Thanks for the informative input, Freeman. >> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good >> >> chance to do this job. When OSGI/Karaf jakarta release is ready, >> >> We can look at bringing this back with more improvement and refactor >> work >> >> to make it loosely coupled with core code. >> >> >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang >> >> wrote: >> >> >> >>> Hi Jim, >> >>> >> >>> Sorry for the late reply, just back from vacation. >> >>> >> >>> About the OSGi part, the main problem is that the OSGi R9 spec which >> will >> >>> support Jakarta namespace is in progress and isn't released yet(and I >> don't >> >>> think there is a concrete release date for OSGi R9 spec in the new >> future). >> >>> Before OSGi R9 spec gets released and adopted by OSGi implementations >> like >> >>> Felix/Equinox, I don't think there is much we can do in CXF or even in >> >>> Karaf about this part. >> >>> >> >>> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit >> >>> seems the only option we have so far, and I'm +1 for this way >> now(Since we >> >>> don't know how long we need to wait for the proper OSGi spec released >> and >> >>> upstream projects can support it). >> >>> >> >>> Just my 2 cents. >> >>> Best Regards >> >>> Freeman >> >>> >> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: >> >>> >> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman >> >>>> about this topic several months ago and got to know >> >>>> there won't be Jakarta namespace support work in the future. I don't >> >>>> know if this has changed. >> >>>> Freeman, do you have some update on this ? >> >>>> >> >>>> >> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko >> wrote: >> >>>> >> >>>>> Hey Jim, >> >>>>> >> >>>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real >> >>>>> blockers. For Swagger 1.x, we could >> >>>>> go ahead and drop the support altogether, this is quite isolated >> >>>>> feature. OSGi and Karaf are not, those >> >>>>> penetrated very deep into core. What worries me, if we drop >> everything >> >>>>> OSGi/Karaf related from 4.0.0, we >> >>>>> may need to bring it back some time in the future (with OSGi R9 [4] >> fe) >> >>>>> and that is going to be quite >> >>>>> difficult
Re: [DISCUSS] CXF 3.5.x and beyond
Hi Jim, It sounds easier, requiring less efforts, I agree. Colm, Freeman, are you on board with this approach guys? Thanks! Best Regards, Andriy Redko JM> Hi Andriy, JM> From what I looked at last time, it seems it's difficult to decouple these JM> osgi/karaf integration code from cxf core JM> and create a new project to put it into a separate repository. IMO, we can JM> create a branch before we JM> remove these integration codes, and later we can look at this branch to JM> restore the osgi/integration code when JM> osgi jakarta support is available. Your thoughts? JM> Thanks, JM> Jim JM> On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko wrote: >> Hey guys, >> >> Thanks a lot for bringing the clarity on possible timelines. @Jim, how do >> you want >> to proceed with that? Do you think it is good idea to move off Apache >> Karaf integration >> into separate repository altogether (we discussed that a few times as >> well)? Should we >> preserve the OSGi-related hooks but replace them with "dummy" >> implementation (like HTTP >> transport for example)? @Colm, @Freeman what do you think? (assuming the >> goal is to put >> this chunk of codebase aside and bring it back when time comes). >> >> Thanks! >> >> Best Regards, >> Andriy Redko >> >> >> > Thanks for the informative input, Freeman. >> > IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good >> > chance to do this job. When OSGI/Karaf jakarta release is ready, >> > We can look at bringing this back with more improvement and refactor work >> > to make it loosely coupled with core code. >> >> > On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang >> wrote: >> >> >> Hi Jim, >> >> >> Sorry for the late reply, just back from vacation. >> >> About the OSGi part, the main problem is that the OSGi R9 spec which >> will >> >> support Jakarta namespace is in progress and isn't released yet(and I >> don't >> >> think there is a concrete release date for OSGi R9 spec in the new >> future). >> >> Before OSGi R9 spec gets released and adopted by OSGi implementations >> like >> >> Felix/Equinox, I don't think there is much we can do in CXF or even in >> >> Karaf about this part. >> >> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit >> >> seems the only option we have so far, and I'm +1 for this way >> now(Since we >> >> don't know how long we need to wait for the proper OSGi spec released >> and >> >> upstream projects can support it). >> >> Just my 2 cents. >> >> Best Regards >> >> Freeman >> >> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: >> >>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman >> >>> about this topic several months ago and got to know >> >>> there won't be Jakarta namespace support work in the future. I don't >> know >> >>> if this has changed. >> >>> Freeman, do you have some update on this ? >> >> >>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko wrote: >> >>>> Hey Jim, >> >> >>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real >> >>>> blockers. For Swagger 1.x, we could >> >>>> go ahead and drop the support altogether, this is quite isolated >> >>>> feature. OSGi and Karaf are not, those >> >>>> penetrated very deep into core. What worries me, if we drop everything >> >>>> OSGi/Karaf related from 4.0.0, we >> >>>> may need to bring it back some time in the future (with OSGi R9 [4] >> fe) >> >>>> and that is going to be quite >> >>>> difficult. From other side, this is probably the only option to have >> >>>> 4.0.0 milestone out (we excluded some >> >>>> modules from the build right now but that is more like a temporary >> hack >> >>>> which we should not release upon, >> >>>> even alphas). What do you think guys? >> >>>> Best Regards, >> >>>> Andriy Redko >> >>>> [1] https://issues.apache.org/jira/browse/CXF-8714 >> >>>> [2] https://issues.apache.org/jira/browse/CXF-8723 >> >>>> [3] https://issues.apache.org/jira/browse/CXF-8722 >> >>>> [4] https://github.com/osgi/osgi/milestone/5 >> JM>>>>> After we me
Re: [DISCUSS] CXF 3.5.x and beyond
Hi Jim, Yeah, we may need some time, I am also finalizing work on the Wiremock (https://github.com/wiremock/wiremock/pull/1942), we use it in tests extensively. One of the largest efforts is migration to Jetty 11, I have started on that already but have difficulties with WebSockets migration, it needs rework and that is my focus at the moment. The Swagger 1.x we have to drop I believe, I don't see roadmap on Jakarta support there. Thanks! Best Regards, Andriy Redko JM> Hi Andriy, JM> It looks like we still have to wait for the other dependency jakarta JM> support available, like brave's new release to include this change : JM> https://github.com/openzipkin/brave/pull/1344. Do you see any other JM> dependencies that haven't been released yet except OSGI and Karaf ? JM> Thanks, JM> Jim JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma wrote: >> Thanks for the informative input, Freeman. >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good >> chance to do this job. When OSGI/Karaf jakarta release is ready, >> We can look at bringing this back with more improvement and refactor work >> to make it loosely coupled with core code. >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang >> wrote: >> >>> Hi Jim, >>> >>> Sorry for the late reply, just back from vacation. >>> >>> About the OSGi part, the main problem is that the OSGi R9 spec which will >>> support Jakarta namespace is in progress and isn't released yet(and I don't >>> think there is a concrete release date for OSGi R9 spec in the new future). >>> Before OSGi R9 spec gets released and adopted by OSGi implementations like >>> Felix/Equinox, I don't think there is much we can do in CXF or even in >>> Karaf about this part. >>> >>> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit >>> seems the only option we have so far, and I'm +1 for this way now(Since we >>> don't know how long we need to wait for the proper OSGi spec released and >>> upstream projects can support it). >>> >>> Just my 2 cents. >>> Best Regards >>> Freeman >>> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: >>> >>>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman >>>> about this topic several months ago and got to know >>>> there won't be Jakarta namespace support work in the future. I don't >>>> know if this has changed. >>>> Freeman, do you have some update on this ? >>>> >>>> >>>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko wrote: >>>> >>>>> Hey Jim, >>>>> >>>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real >>>>> blockers. For Swagger 1.x, we could >>>>> go ahead and drop the support altogether, this is quite isolated >>>>> feature. OSGi and Karaf are not, those >>>>> penetrated very deep into core. What worries me, if we drop everything >>>>> OSGi/Karaf related from 4.0.0, we >>>>> may need to bring it back some time in the future (with OSGi R9 [4] fe) >>>>> and that is going to be quite >>>>> difficult. From other side, this is probably the only option to have >>>>> 4.0.0 milestone out (we excluded some >>>>> modules from the build right now but that is more like a temporary hack >>>>> which we should not release upon, >>>>> even alphas). What do you think guys? >>>>> >>>>> Best Regards, >>>>> Andriy Redko >>>>> >>>>> [1] https://issues.apache.org/jira/browse/CXF-8714 >>>>> [2] https://issues.apache.org/jira/browse/CXF-8723 >>>>> [3] https://issues.apache.org/jira/browse/CXF-8722 >>>>> [4] https://github.com/osgi/osgi/milestone/5 >>>>> >>>>> JM> After we merged the jakarta branch to default branch main branch, >>>>> do we >>>>> JM> need to create some >>>>> JM> plan to do a future 4.x release? >>>>> >>>>> JM> There are a couple of to-do things under >>>>> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, >>>>> JM> and for some of them we can't do more things because of the jakarta >>>>> JM> dependency missing. It seems that some of the dependencies won't >>>>> JM> have the jakarta namespace artifact released in the near future. >>>>> Should we >
Re: [DISCUSS] CXF 3.5.x and beyond
Hey guys, Thanks a lot for bringing the clarity on possible timelines. @Jim, how do you want to proceed with that? Do you think it is good idea to move off Apache Karaf integration into separate repository altogether (we discussed that a few times as well)? Should we preserve the OSGi-related hooks but replace them with "dummy" implementation (like HTTP transport for example)? @Colm, @Freeman what do you think? (assuming the goal is to put this chunk of codebase aside and bring it back when time comes). Thanks! Best Regards, Andriy Redko > Thanks for the informative input, Freeman. > IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good > chance to do this job. When OSGI/Karaf jakarta release is ready, > We can look at bringing this back with more improvement and refactor work > to make it loosely coupled with core code. > On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang wrote: >> Hi Jim, >> Sorry for the late reply, just back from vacation. >> About the OSGi part, the main problem is that the OSGi R9 spec which will >> support Jakarta namespace is in progress and isn't released yet(and I don't >> think there is a concrete release date for OSGi R9 spec in the new future). >> Before OSGi R9 spec gets released and adopted by OSGi implementations like >> Felix/Equinox, I don't think there is much we can do in CXF or even in >> Karaf about this part. >> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit >> seems the only option we have so far, and I'm +1 for this way now(Since we >> don't know how long we need to wait for the proper OSGi spec released and >> upstream projects can support it). >> Just my 2 cents. >> Best Regards >> Freeman >> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: >>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman >>> about this topic several months ago and got to know >>> there won't be Jakarta namespace support work in the future. I don't know >>> if this has changed. >>> Freeman, do you have some update on this ? >>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko wrote: >>>> Hey Jim, >>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real >>>> blockers. For Swagger 1.x, we could >>>> go ahead and drop the support altogether, this is quite isolated >>>> feature. OSGi and Karaf are not, those >>>> penetrated very deep into core. What worries me, if we drop everything >>>> OSGi/Karaf related from 4.0.0, we >>>> may need to bring it back some time in the future (with OSGi R9 [4] fe) >>>> and that is going to be quite >>>> difficult. From other side, this is probably the only option to have >>>> 4.0.0 milestone out (we excluded some >>>> modules from the build right now but that is more like a temporary hack >>>> which we should not release upon, >>>> even alphas). What do you think guys? >>>> Best Regards, >>>> Andriy Redko >>>> [1] https://issues.apache.org/jira/browse/CXF-8714 >>>> [2] https://issues.apache.org/jira/browse/CXF-8723 >>>> [3] https://issues.apache.org/jira/browse/CXF-8722 >>>> [4] https://github.com/osgi/osgi/milestone/5 JM>>>>> After we merged the jakarta branch to default branch main branch, >>>> do we JM>>>>> need to create some JM>>>>> plan to do a future 4.x release? JM>>>>> There are a couple of to-do things under JM>>>>> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, JM>>>>> and for some of them we can't do more things because of the jakarta JM>>>>> dependency missing. It seems that some of the dependencies won't JM>>>>> have the jakarta namespace artifact released in the near future. >>>> Should we JM>>>>> have some milestone/alpha release JM>>>>> before all these dependencies are available ? And if we want to do a JM>>>>> milestone release, what do you think we should have in JM>>>>> this 4.0.0-M1 release ? JM>>>>> Thanks, JM>>>>> Jim JM>>>>> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma >>>> wrote: >>>>>> Thanks Andriy too for driving this and moving forward ! >>>>>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko >>>> wrote: >>>>>>> Hey guys, >>>>>>> The Jakarta branch [1] just went into master, HUGE THANKS everyone >>>> for >>>>>>> tremendous effort! Please &g
