[jira] [Commented] (CXF-9063) OpenTelemetry context leak with CXF async client
[ https://issues.apache.org/jira/browse/CXF-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886953#comment-17886953 ] Andriy Redko commented on CXF-9063: --- Awesome, thanks a lot [~ffang]! > OpenTelemetry context leak with CXF async client > > > Key: CXF-9063 > URL: https://issues.apache.org/jira/browse/CXF-9063 > Project: CXF > Issue Type: Bug > Components: Core, Tracing >Affects Versions: 4.0.5 >Reporter: Matthew Robson >Priority: Major > > There seems to be a Otel context leak when using a CXF producer in async > mode. This causes different requests to have the same traceId. As a > workaround, setting synchronous=true on the CXF producer resolves the issue. > Unit test to reproduce added to camel: > https://github.com/apache/camel/blob/7d83a62b8e442dc9ac6fd79b153192add940301e/components/camel-opentelemetry/src/test/java/org/apache/camel/opentelemetry/AsyncCxfTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9064) AsyncHTTPConduit doesn't close wrappedStream on close
[ https://issues.apache.org/jira/browse/CXF-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886809#comment-17886809 ] Andriy Redko commented on CXF-9064: --- Thanks [~exprompt], the wrappedStream is closed by `super.close()` call chain, more specifically AbstractWrappedOutputStream::close() (if it is not cached), does it address your concern? Thank you. > AsyncHTTPConduit doesn't close wrappedStream on close > - > > Key: CXF-9064 > URL: https://issues.apache.org/jira/browse/CXF-9064 > Project: CXF > Issue Type: Bug >Affects Versions: 3.6.4 >Reporter: Alexey Deryabin >Priority: Major > > I found that in > org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream > on close method the wrappedStream is not closed but reassigned to the new > anonymous OutputStream in handleHeadersTrustCaching by setupWrappedStream. > It is in cxf-rt-transports-http-hc module. > My suggest to add out.close() on 426 line. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9063) OpenTelemetry context leak with CXF async client
[ https://issues.apache.org/jira/browse/CXF-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886808#comment-17886808 ] Andriy Redko commented on CXF-9063: --- Thanks [~mrobson], will look at it shortly > OpenTelemetry context leak with CXF async client > > > Key: CXF-9063 > URL: https://issues.apache.org/jira/browse/CXF-9063 > Project: CXF > Issue Type: Bug > Components: Core, Tracing >Affects Versions: 4.0.5 >Reporter: Matthew Robson >Priority: Major > > There seems to be a Otel context leak when using a CXF producer in async > mode. This causes different requests to have the same traceId. As a > workaround, setting synchronous=true on the CXF producer resolves the issue. > Unit test to reproduce added to camel: > https://github.com/apache/camel/blob/7d83a62b8e442dc9ac6fd79b153192add940301e/components/camel-opentelemetry/src/test/java/org/apache/camel/opentelemetry/AsyncCxfTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886385#comment-17886385
]
Andriy Redko commented on CXF-9057:
---
Thank you!
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
> What should happen instead is that the response should be closed without
> sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
> For example when we use a Servlet to stream data to a client a throw an
> exception the result will look something like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Fri, 13 Sep 2024 09:31:48 GMT
> Content-Type: text/plain;charset=utf-8
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8
> Chunk 1
> 8
> Chunk 2
> 8
> Chunk 3
> 8
> Chunk 4
> 8
> Chunk 5
> {code}
> Here there is no closing 0 marker. As a result clients can recognise the
> error. (Curl will report "curl: (18) transfer closed with outstanding read
> data remaining", Chrome "Failed to load resource:
> net::ERR_INCOMPLETE_CHUNKED_ENCODING")
> CXF should do the same and not end the chunked stream regularly, when an
> exception is thrown.
> I have tested with Tomcat and Jetty. Both show the same behaviour.
> To provide some detail, Exceptions are caught by CXF here:
> org/apache/cxf/phase/PhaseInterceptorChain.java:328
> {code:java}
> } catch (RuntimeException ex) {
> if (!faultOccurred) {
> faultOccurred = true;
> wrapExceptionAsFault(message, ex);
> }
> state = State.ABORTED;
> }
> {code}
> The exception is logged, but not rethrown.
> If the exception would be thrown, for instance Tomcats ErrorReportValve would
> shut down the output and thereby prevent the end of the input and closing 0
> to be written.
> org/apache/catalina/valves/ErrorReportValve.java:112
> {code:java}
> // Now close immediately to signal to the client that
> // something went wrong
> response.getCoyoteResponse().action(ActionCode.CLOSE_NOW,
>
> request.getAttribute(RequestDispatcher.ERROR_EXCEPTION));
> {code}
> Without an exception to prevent this, a regular end of the stream will be
> written by
> org/apache/catalina/connector/CoyoteAdapter.java:371
> response.finishResponse();
> In Summary: CXF ends a chu
[jira] [Commented] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886297#comment-17886297
]
Andriy Redko commented on CXF-9057:
---
Thanks [~johannes.herr], do you by any chance have a reproducible test case (or
application) for this issue? thank you
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
> What should happen instead is that the response should be closed without
> sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
> For example when we use a Servlet to stream data to a client a throw an
> exception the result will look something like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Fri, 13 Sep 2024 09:31:48 GMT
> Content-Type: text/plain;charset=utf-8
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8
> Chunk 1
> 8
> Chunk 2
> 8
> Chunk 3
> 8
> Chunk 4
> 8
> Chunk 5
> {code}
> Here there is no closing 0 marker. As a result clients can recognise the
> error. (Curl will report "curl: (18) transfer closed with outstanding read
> data remaining", Chrome "Failed to load resource:
> net::ERR_INCOMPLETE_CHUNKED_ENCODING")
> CXF should do the same and not end the chunked stream regularly, when an
> exception is thrown.
> I have tested with Tomcat and Jetty. Both show the same behaviour.
> To provide some detail, Exceptions are caught by CXF here:
> org/apache/cxf/phase/PhaseInterceptorChain.java:328
> {code:java}
> } catch (RuntimeException ex) {
> if (!faultOccurred) {
> faultOccurred = true;
> wrapExceptionAsFault(message, ex);
> }
> state = State.ABORTED;
> }
> {code}
> The exception is logged, but not rethrown.
> If the exception would be thrown, for instance Tomcats ErrorReportValve would
> shut down the output and thereby prevent the end of the input and closing 0
> to be written.
> org/apache/catalina/valves/ErrorReportValve.java:112
> {code:java}
> // Now close immediately to signal to the client that
> // something went wrong
> response.getCoyoteResponse().action(ActionCode.CLOSE_NOW,
>
> request.getAttribute(RequestDispatcher.ERROR_EXCEPTION));
> {code}
> Without an exception to prevent this, a regular end of the stream will be
> written by
> o
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/] [)|https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - Hibernate Validator 9 (https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0.1), https://github.com/apache/cxf/pull/2078] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - [https://microprofile.io/2024/08/22/microprofile-7-0-release/|https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar] was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/] [)|https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - Hibernate Validator 9 (https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0.1), https://github.com/apache/cxf/pull/2078] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - [https://microprofile.io/2024/08/22/microprofile-7-0-release/|https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar] was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container
[jira] [Comment Edited] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885612#comment-17885612 ] Andriy Redko edited comment on CXF-7396 at 9/28/24 8:20 PM: In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients). *As a workaround,* the CachedOutputStreamCleaner bus extension could be used to provide the custom cleaning mechanism for such dangling cached streams (by default, the extension is implemented by DelayedCachedOutputStreamCleaner and run periodic cleanup set by bus.io.CachedOutputStreamCleaner.Delay bus property, which is set to 30 mins by default). Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/Securing+CXF+Services#SecuringCXFServices-Largedatastreamcaching was (Author: reta): In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients). *As a workaround,* the CachedOutputStreamCleaner bus extension could be used to provide the custom cleaning mechanism for such dangling cached streams (by default, the extension is implemented by DelayedCachedOutputStreamCleaner and run periodic cleanup set by bus.io.CachedOutputStreamCleaner.Delay bus property, 30 mins by default). Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/Securing+CXF+Services#SecuringCXFServices-Largedatastreamcaching > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.10, 3.6.5, 4.0.6 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885612#comment-17885612 ] Andriy Redko commented on CXF-7396: --- In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients). *As a workaround,* the CachedOutputStreamCleaner bus extension could be used to provide the custom cleaning mechanism for such dangling cached streams (by default, the extension is implemented by DelayedCachedOutputStreamCleaner and run periodic cleanup set by bus.io.CachedOutputStreamCleaner.Delay bus property, 30 mins by default). Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/Securing+CXF+Services#SecuringCXFServices-Largedatastreamcaching > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.10, 3.6.5, 4.0.6 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-7396. --- Resolution: Fixed > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.10, 3.6.5, 4.0.6 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/] [)|https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0.1), https://github.com/apache/cxf/pull/2078] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - [https://microprofile.io/2024/08/22/microprofile-7-0-release/|https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar] was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.
[jira] [Assigned] (CXF-9061) Update documentation to use Jakarta namespaces as well (where appropriate)
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-9061: - Assignee: Andriy Redko > Update documentation to use Jakarta namespaces as well (where appropriate) > -- > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > > For 4.0.x release, most of XML namespaces have to be switched to Jakarta > equivalent ones but our documentation still refers to Java EE mostly > everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We > have to update the documentation to show off both options, see please an > example of recently fixed documentation here: > https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces as well (where appropriate)
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Summary: Update documentation to use Jakarta namespaces as well (where appropriate) (was: Update documentation to use Jakarta namespaces where appropriate) > Update documentation to use Jakarta namespaces as well (where appropriate) > -- > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > > For 4.0.x release, most of XML namespaces have to be switched to Jakarta > equivalent ones but our documentation still refers to Java EE mostly > everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We > have to update the documentation to show off both options, see please an > example of recently fixed documentation here: > https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9058.
---
Resolution: Fixed
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Description: For 4.0.x release, most of XML namespaces have to be switched to Jakarta equivalent ones but our documentation still refers to Java EE mostly everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We have to update the documentation to show off both options, see please an example of recently fixed documentation here: https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java > Update documentation to use Jakarta namespaces where appropriate > > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > > For 4.0.x release, most of XML namespaces have to be switched to Jakarta > equivalent ones but our documentation still refers to Java EE mostly > everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We > have to update the documentation to show off both options, see please an > example of recently fixed documentation here: > https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Fix Version/s: 4.1.0 4.0.6 > Update documentation to use Jakarta namespaces where appropriate > > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Affects Version/s: 4.0.5 > Update documentation to use Jakarta namespaces where appropriate > > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883517#comment-17883517
]
Andriy Redko commented on CXF-9058:
---
Updated https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java with
3.6.x and 4.0.x variants
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
Andriy Redko created CXF-9061: - Summary: Update documentation to use Jakarta namespaces where appropriate Key: CXF-9061 URL: https://issues.apache.org/jira/browse/CXF-9061 Project: CXF Issue Type: Bug Reporter: Andriy Redko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9059.
---
Resolution: Fixed
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Assignee: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9060) WSDL2Java Service generation results in 'unused import' warnings
[
https://issues.apache.org/jira/browse/CXF-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9060.
---
Resolution: Fixed
> WSDL2Java Service generation results in 'unused import' warnings
>
>
> Key: CXF-9060
> URL: https://issues.apache.org/jira/browse/CXF-9060
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.5
>Reporter: Andrew Gibb
>Priority: Minor
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> After the fix for CXF-9011 there are now "unused import" warnings for
> {{java.net.URI}} in some generated Services. This is because the
> {{URI.create(...).toUrl()}} is only used in some scenarios.
>
> There is already a conditional check in the {{service.vm}} template around
> the import for {{java.net.MalformedURLException}} which is used in the same
> scenario when creating the URL so I believe the import for {{java.net.URI}}
> belongs in there as well.
>
> I have tested the conditional import and will submit a pull request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9060) WSDL2Java Service generation results in 'unused import' warnings
[
https://issues.apache.org/jira/browse/CXF-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9060:
--
Fix Version/s: 3.6.5
> WSDL2Java Service generation results in 'unused import' warnings
>
>
> Key: CXF-9060
> URL: https://issues.apache.org/jira/browse/CXF-9060
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.5
>Reporter: Andrew Gibb
>Priority: Minor
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> After the fix for CXF-9011 there are now "unused import" warnings for
> {{java.net.URI}} in some generated Services. This is because the
> {{URI.create(...).toUrl()}} is only used in some scenarios.
>
> There is already a conditional check in the {{service.vm}} template around
> the import for {{java.net.MalformedURLException}} which is used in the same
> scenario when creating the URL so I believe the import for {{java.net.URI}}
> belongs in there as well.
>
> I have tested the conditional import and will submit a pull request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-9059:
-
Assignee: Jamie Mark Goodyear
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Assignee: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Fix Version/s: 3.6.5
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Fix Version/s: 4.0.6
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.1.0
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Affects Version/s: 3.6.4
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Affects Version/s: 4.0.5
(was: 4.1.0)
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9060) WSDL2Java Service generation results in 'unused import' warnings
[
https://issues.apache.org/jira/browse/CXF-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9060:
--
Fix Version/s: 4.1.0
4.0.6
> WSDL2Java Service generation results in 'unused import' warnings
>
>
> Key: CXF-9060
> URL: https://issues.apache.org/jira/browse/CXF-9060
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.5
>Reporter: Andrew Gibb
>Priority: Minor
> Fix For: 4.1.0, 4.0.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> After the fix for CXF-9011 there are now "unused import" warnings for
> {{java.net.URI}} in some generated Services. This is because the
> {{URI.create(...).toUrl()}} is only used in some scenarios.
>
> There is already a conditional check in the {{service.vm}} template around
> the import for {{java.net.MalformedURLException}} which is used in the same
> scenario when creating the URL so I believe the import for {{java.net.URI}}
> belongs in there as well.
>
> I have tested the conditional import and will submit a pull request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883122#comment-17883122 ] Andriy Redko edited comment on CXF-9039 at 9/19/24 9:35 PM: Failing tests on initial run: * [ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext.JAXRSClientIT.getEntityAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext/JAXRSClientIT/getEntityAnnotationsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.response.JAXRSClientIT.responseCreatedRelativeURITest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.response/JAXRSClientIT/responseCreatedRelativeURITest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder.JAXRSClientIT.entityObjectTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder/JAXRSClientIT/entityObjectTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest1|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest1/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest2|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest2/] * [ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext.JAXRSClientIT.getAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext/JAXRSClientIT/getAnnotationsTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster.JAXRSClientIT.sseBroadcastTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster/JAXRSClientIT/sseBroadcastTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.stringTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/stringTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.streamingOutputTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/streamingOutputTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.fileTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/fileTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.closeTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/closeTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.inputstreamTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/inputstreamTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.readerTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/readerTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.transformSourceTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/transformSourceTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.multivaluedMapTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/multivaluedMapTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.jaxbElementTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/jaxbElementTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.sseStageCheckTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/sseStageCheckTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.doubleTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/do
[jira] [Commented] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883122#comment-17883122 ] Andriy Redko commented on CXF-9039: --- * [ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext.JAXRSClientIT.getEntityAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext/JAXRSClientIT/getEntityAnnotationsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.response.JAXRSClientIT.responseCreatedRelativeURITest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.response/JAXRSClientIT/responseCreatedRelativeURITest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder.JAXRSClientIT.entityObjectTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder/JAXRSClientIT/entityObjectTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest1|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest1/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest2|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest2/] * [ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext.JAXRSClientIT.getAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext/JAXRSClientIT/getAnnotationsTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster.JAXRSClientIT.sseBroadcastTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster/JAXRSClientIT/sseBroadcastTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.stringTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/stringTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.streamingOutputTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/streamingOutputTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.fileTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/fileTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.closeTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/closeTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.inputstreamTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/inputstreamTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.readerTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/readerTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.transformSourceTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/transformSourceTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.multivaluedMapTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/multivaluedMapTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.jaxbElementTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/jaxbElementTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.sseStageCheckTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/sseStageCheckTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.doubleTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/doubleTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.d
[jira] [Updated] (CXF-9038) Run Jakarta RESTful Web Services 3.0 TCK
[ https://issues.apache.org/jira/browse/CXF-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9038: -- Description: Run Jakarta RESTful Web Services 3.0 TCK (JakarteEE 9.1): https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.0-TCK Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.0TCK was:Run Jakarta RESTful Web Services 3.0 TCK (JakarteEE 9.1): https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.0-TCK > Run Jakarta RESTful Web Services 3.0 TCK > > > Key: CXF-9038 > URL: https://issues.apache.org/jira/browse/CXF-9038 > Project: CXF > Issue Type: Improvement >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.6 > > > Run Jakarta RESTful Web Services 3.0 TCK (JakarteEE 9.1): > https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.0-TCK > Documentation: > https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.0TCK -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9039: -- Description: Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). It seems like the Jakarta EE 10 jaxrs TCK is split between: - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] - [https://github.com/jakartaee/platform-tck/tree/10.0.5] Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.1TCK was: Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). It seems like the Jakarta EE 10 jaxrs TCK is split between: - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] - https://github.com/jakartaee/platform-tck/tree/10.0.5 > Run Jakarta RESTful Web Services 3.1 TCK > > > Key: CXF-9039 > URL: https://issues.apache.org/jira/browse/CXF-9039 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). > It seems like the Jakarta EE 10 jaxrs TCK is split between: > - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] > - [https://github.com/jakartaee/platform-tck/tree/10.0.5] > Documentation: > https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.1TCK -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883032#comment-17883032 ] Andriy Redko commented on CXF-9039: --- https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/ > Run Jakarta RESTful Web Services 3.1 TCK > > > Key: CXF-9039 > URL: https://issues.apache.org/jira/browse/CXF-9039 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). > It seems like the Jakarta EE 10 jaxrs TCK is split between: > - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] > - https://github.com/jakartaee/platform-tck/tree/10.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-9058:
-
Assignee: Andriy Redko
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9058:
--
Fix Version/s: 4.1.0
4.0.6
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9039: -- Description: Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). It seems like the Jakarta EE 10 jaxrs TCK is split between: - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] - https://github.com/jakartaee/platform-tck/tree/10.0.5 was:Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10) > Run Jakarta RESTful Web Services 3.1 TCK > > > Key: CXF-9039 > URL: https://issues.apache.org/jira/browse/CXF-9039 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). > It seems like the Jakarta EE 10 jaxrs TCK is split between: > - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] > - https://github.com/jakartaee/platform-tck/tree/10.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9055: -- Fix Version/s: 3.5.10 > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9055: -- Fix Version/s: 3.6.5 > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9055. --- Resolution: Fixed > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9055: -- Fix Version/s: 4.0.6 > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXFXJC-49.
Resolution: Fixed
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.1.0, 4.0.3, 3.3.5
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Fix Version/s: 4.1.0
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.1.0, 4.0.3, 3.3.5
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Fix Version/s: 4.0.3
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.0.3
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Affects Version/s: 3.3.4
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.0.3
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Fix Version/s: 3.3.5
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.0.3, 3.3.5
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880627#comment-17880627
]
Andriy Redko commented on CXF-9053:
---
[~davidbp] I don't think that Bazel produces a valid self-contained, deployable
JAR, please check [1], [2], per my understanding the META-INF/* entries are
not processed properly, hence you run into issues:
[1] [https://github.com/bazelbuild/bazel/issues/7330]
[2] https://github.com/bazelbuild/bazel/issues/21722
> NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when
> deploying application
> -
>
> Key: CXF-9053
> URL: https://issues.apache.org/jira/browse/CXF-9053
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: David Butragueno Palomar
>Priority: Minor
>
> I am using Apache CXF in a Java application built with Bazel to make requests
> to an external web service. When deploying the microservice locally, for
> example, using IntelliJ IDEA, the application deploys successfully and works
> as expected. However, when deploying the application within a Docker
> container, the microservice fails to deploy due to the following error:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
> ~[service_deploy.jar:?] {code}
>
> *Apache CXF dependencies*
> org.apache.cxf:cxf-rt-ws-security
> org.apache.cxf:cxf-rt-frontend-jaxws
> org.apache.cxf:cxf-rt-transports-http
>
>
> *JVM options*
>
> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
> -Dlog4j2.configurationFile=/resources/log4j2.xml
> -Dlog4j2.debug=true
>
> *Technical specifications*
> Apache CXF version: 3.5.1
> Java versión: 11.0.4
> Bazel version: 6.3.2
> Docker version: 20.10.12
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880442#comment-17880442
]
Andriy Redko commented on CXF-9053:
---
[~davidbp] the problem is very likely related to the way you package your
application inside the container (fat jar? ...), more details would help here,
thank you.
> NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when
> deploying application
> -
>
> Key: CXF-9053
> URL: https://issues.apache.org/jira/browse/CXF-9053
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: David Butragueno Palomar
>Priority: Minor
>
> I am using Apache CXF in a Java application built with Bazel to make requests
> to an external web service. When deploying the microservice locally, for
> example, using IntelliJ IDEA, the application deploys successfully and works
> as expected. However, when deploying the application within a Docker
> container, the microservice fails to deploy due to the following error:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
> ~[service_deploy.jar:?] {code}
>
> *Apache CXF dependencies*
> org.apache.cxf:cxf-rt-ws-security
> org.apache.cxf:cxf-rt-frontend-jaxws
> org.apache.cxf:cxf-rt-transports-http
>
>
> *JVM options*
>
> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
> -Dlog4j2.configurationFile=/resources/log4j2.xml
> -Dlog4j2.debug=true
>
> *Technical specifications*
> Apache CXF version: 3.5.1
> Java versión: 11.0.4
> Bazel version: 6.3.2
> Docker version: 20.10.12
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8624) CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
[
https://issues.apache.org/jira/browse/CXF-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880173#comment-17880173
]
Andriy Redko commented on CXF-8624:
---
The JAXB spec [1] is a best place to have the support for JSR 310, the
[threeten-jaxb|https://github.com/threeten-jaxb/threeten-jaxb] seems to be
filling this gap at the moment.
[1] https://github.com/eclipse-ee4j/jaxb-ri/issues/1174
> CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
>
>
> Key: CXF-8624
> URL: https://issues.apache.org/jira/browse/CXF-8624
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.12, 3.4.5
>Reporter: Anthony Durussel
>Assignee: Andriy Redko
>Priority: Major
>
> If you use the @QueryParam("") extension on a method parameter:
> {code:java}
> public void foo(@QueryParam("") Bar bar);
> {code}
> with Bar class equals to :
> {code:java}
> public class Bar {
> private LocalDate date;
> } {code}
> The URL generate from the following method parse the localDate as a standard
> object instead of singleValue as it's done for standard java.util.date
> {code:java}
> org.apache.cxf.jaxrs.utils.InjectionUtils.fillInValuesFromBean(Object,
> String, MultivaluedMap)
> {code}
> {code:java}
> if (isPrimitive(value.getClass()) ||
> Date.class.isAssignableFrom(value.getClass())) {
> values.putSingle(propertyName, value);
> } else if (value.getClass().isEnum()) {
> values.putSingle(propertyName, value.toString());
> } else if (isSupportedCollectionOrArray(value.getClass())) {
> final List theValues;
> if (value.getClass().isArray()) {
> theValues = Arrays.asList((Object[])value);
> } else if (value instanceof Set) {
> theValues = new ArrayList<>((Set)value);
> } else {
> theValues = CastUtils.cast((List)value);
> }
> values.put(propertyName, theValues);
> } else if (Map.class.isAssignableFrom(value.getClass())) {
> if (isSupportedMap(m.getGenericReturnType())) {
> Map map = CastUtils.cast((Map)value);
> for (Map.Entry entry : map.entrySet()) {
> values.add(propertyName + '.' + entry.getKey().toString(),
> entry.getValue().toString());
> }
> }
> } else {
> fillInValuesFromBean(value, propertyName, values);
> }{code}
> Ideally, we should add the LocalDate in the first "if condition" to handle it
> correctly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8624) CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
[
https://issues.apache.org/jira/browse/CXF-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880173#comment-17880173
]
Andriy Redko edited comment on CXF-8624 at 9/8/24 6:57 PM:
---
The JAXB spec [1] is the best place to have the support for JSR 310, the
[threeten-jaxb|https://github.com/threeten-jaxb/threeten-jaxb] seems to be
filling this gap at the moment.
[1] [https://github.com/eclipse-ee4j/jaxb-ri/issues/1174]
was (Author: reta):
The JAXB spec [1] is a best place to have the support for JSR 310, the
[threeten-jaxb|https://github.com/threeten-jaxb/threeten-jaxb] seems to be
filling this gap at the moment.
[1] https://github.com/eclipse-ee4j/jaxb-ri/issues/1174
> CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
>
>
> Key: CXF-8624
> URL: https://issues.apache.org/jira/browse/CXF-8624
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.12, 3.4.5
>Reporter: Anthony Durussel
>Assignee: Andriy Redko
>Priority: Major
>
> If you use the @QueryParam("") extension on a method parameter:
> {code:java}
> public void foo(@QueryParam("") Bar bar);
> {code}
> with Bar class equals to :
> {code:java}
> public class Bar {
> private LocalDate date;
> } {code}
> The URL generate from the following method parse the localDate as a standard
> object instead of singleValue as it's done for standard java.util.date
> {code:java}
> org.apache.cxf.jaxrs.utils.InjectionUtils.fillInValuesFromBean(Object,
> String, MultivaluedMap)
> {code}
> {code:java}
> if (isPrimitive(value.getClass()) ||
> Date.class.isAssignableFrom(value.getClass())) {
> values.putSingle(propertyName, value);
> } else if (value.getClass().isEnum()) {
> values.putSingle(propertyName, value.toString());
> } else if (isSupportedCollectionOrArray(value.getClass())) {
> final List theValues;
> if (value.getClass().isArray()) {
> theValues = Arrays.asList((Object[])value);
> } else if (value instanceof Set) {
> theValues = new ArrayList<>((Set)value);
> } else {
> theValues = CastUtils.cast((List)value);
> }
> values.put(propertyName, theValues);
> } else if (Map.class.isAssignableFrom(value.getClass())) {
> if (isSupportedMap(m.getGenericReturnType())) {
> Map map = CastUtils.cast((Map)value);
> for (Map.Entry entry : map.entrySet()) {
> values.add(propertyName + '.' + entry.getKey().toString(),
> entry.getValue().toString());
> }
> }
> } else {
> fillInValuesFromBean(value, propertyName, values);
> }{code}
> Ideally, we should add the LocalDate in the first "if condition" to handle it
> correctly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8624) CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
[
https://issues.apache.org/jira/browse/CXF-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879974#comment-17879974
]
Andriy Redko commented on CXF-8624:
---
[~Didier Loiseau] the {{JavaTimeTypesParamConverterProvider }}is a regular
JAX-RS {color:#00}{color:#00}ParamConverterProvider{color}{color} (see
please
[https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ParamConverterProvider.html])
which converts from String to Java 8 JSR 310 Date Time API. I don't think we
have dedicated documentation for it at the moment.
> Is there a convenient way to generate classes using {{java.time}} without
> rolling your own adapters and bindings file?
What kind of generator you are using? cxf-wadl2java-plugin or something else?
> CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
>
>
> Key: CXF-8624
> URL: https://issues.apache.org/jira/browse/CXF-8624
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.12, 3.4.5
>Reporter: Anthony Durussel
>Assignee: Andriy Redko
>Priority: Major
>
> If you use the @QueryParam("") extension on a method parameter:
> {code:java}
> public void foo(@QueryParam("") Bar bar);
> {code}
> with Bar class equals to :
> {code:java}
> public class Bar {
> private LocalDate date;
> } {code}
> The URL generate from the following method parse the localDate as a standard
> object instead of singleValue as it's done for standard java.util.date
> {code:java}
> org.apache.cxf.jaxrs.utils.InjectionUtils.fillInValuesFromBean(Object,
> String, MultivaluedMap)
> {code}
> {code:java}
> if (isPrimitive(value.getClass()) ||
> Date.class.isAssignableFrom(value.getClass())) {
> values.putSingle(propertyName, value);
> } else if (value.getClass().isEnum()) {
> values.putSingle(propertyName, value.toString());
> } else if (isSupportedCollectionOrArray(value.getClass())) {
> final List theValues;
> if (value.getClass().isArray()) {
> theValues = Arrays.asList((Object[])value);
> } else if (value instanceof Set) {
> theValues = new ArrayList<>((Set)value);
> } else {
> theValues = CastUtils.cast((List)value);
> }
> values.put(propertyName, theValues);
> } else if (Map.class.isAssignableFrom(value.getClass())) {
> if (isSupportedMap(m.getGenericReturnType())) {
> Map map = CastUtils.cast((Map)value);
> for (Map.Entry entry : map.entrySet()) {
> values.add(propertyName + '.' + entry.getKey().toString(),
> entry.getValue().toString());
> }
> }
> } else {
> fillInValuesFromBean(value, propertyName, values);
> }{code}
> Ideally, we should add the LocalDate in the first "if condition" to handle it
> correctly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko closed CXF-9050.
-
Resolution: Won't Fix
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
>
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878357#comment-17878357
]
Andriy Redko edited comment on CXF-9050 at 8/31/24 3:38 PM:
[~this.romanov] Apache CXF 3.6.x branch uses 'javax.' ** namespaces (moreover,
Swagger Core 1.6.x only works with 'javax.'), please check your dependencies.
was (Author: reta):
[~this.romanov] Apache CXF 3.6.x branch uses `javax.*` namespaces (moreover,
Swagger Core 1.6.x only works with `javax.*`), please check your dependencies.
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
>
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878357#comment-17878357
]
Andriy Redko commented on CXF-9050:
---
[~this.romanov] Apache CXF 3.6.x branch uses `javax.*` namespaces (moreover,
Swagger Core 1.6.x only works with `javax.*`), please check your dependencies.
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
>
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878252#comment-17878252 ] Andriy Redko commented on CXF-8931: --- Hi [~bodhione] , yes > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0-RC4)] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/0
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0-RC4)] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - [https://microprofile.io/2024/08/22/microprofile-7-0-release/|https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar] was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validato
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0-RC4)] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], https://github.com/apache/cxf/pull/2028) was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 (https://in.relation.to/2024/08/01/orm-70-beta1/) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-o
[jira] [Commented] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876439#comment-17876439 ] Andriy Redko commented on CXF-8629: --- [~bocamel] I have working on this issue but I cannot reproduce this double logging (for response) problem you've been running into. Would you be able to supply a reproducer (project or test case, whatever is easier for you). Thank you. > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9048) Failed integration tests with upcomming santuario and wss4j library
[ https://issues.apache.org/jira/browse/CXF-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9048: -- Affects Version/s: (was: 4.1.0) > Failed integration tests with upcomming santuario and wss4j library > --- > > Key: CXF-9048 > URL: https://issues.apache.org/jira/browse/CXF-9048 > Project: CXF > Issue Type: Test > Components: WS-* Components >Reporter: Joze Rihtarsic >Priority: Major > Fix For: 4.1.0 > > > The latest release of the Santuario library (version 3.0.5) and WSS4j > (version 3.0.4) introduces support for the HKDF derivation function, which is > now the default for encryption key derivation when using the Key Agreement > method. However, the integration tests currently default to the older > ConcatKDF. This ticket aims to align the integration tests with the updated > default behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876294#comment-17876294 ] Andriy Redko commented on CXF-8931: --- Thanks for looking [~bodhione] . Right, the `reset()` is not needed since the stream is buffered and consumed only once, thanks! > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9048) Failed integration tests with upcomming santuario and wss4j library
[ https://issues.apache.org/jira/browse/CXF-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876295#comment-17876295 ] Andriy Redko commented on CXF-9048: --- Thanks [~jrihtarsic] (I just cleared 4.1.0 affected version since it is not released yet) > Failed integration tests with upcomming santuario and wss4j library > --- > > Key: CXF-9048 > URL: https://issues.apache.org/jira/browse/CXF-9048 > Project: CXF > Issue Type: Test > Components: WS-* Components >Reporter: Joze Rihtarsic >Priority: Major > Fix For: 4.1.0 > > > The latest release of the Santuario library (version 3.0.5) and WSS4j > (version 3.0.4) introduces support for the HKDF derivation function, which is > now the default for encryption key derivation when using the Key Agreement > method. However, the integration tests currently default to the older > ConcatKDF. This ticket aims to align the integration tests with the updated > default behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876042#comment-17876042 ] Andriy Redko commented on CXF-8931: --- [~bodhione] could you please give [https://github.com/apache/cxf/pull/2018] a try? Thank you. > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8629: -- Fix Version/s: 4.1.0 > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXFXJC-47) XJC DefaultValue plugin uses JAXBElement that does not have a default constructor
[
https://issues.apache.org/jira/browse/CXFXJC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-47:
---
Fix Version/s: 4.0.2
(was: 4.0.1)
> XJC DefaultValue plugin uses JAXBElement that does not have a default
> constructor
> -
>
> Key: CXFXJC-47
> URL: https://issues.apache.org/jira/browse/CXFXJC-47
> Project: CXF XJC Utils
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 3.3.4, 4.0.2
>
>
> As reported by the user (see please
> https://github.com/apache/cxf-xjc-utils/pull/129):
> We've found a minor bug when using extensions and substitiongroups.
> The defaultvalue-plugin generates a {{new JAXBElement}} expression, which
> isn't valid java code, as JAXBElement does not have a default constructor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8840) Introduce HTTP/2 Transport: client-side support using JDK's HttpClient
[ https://issues.apache.org/jira/browse/CXF-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873749#comment-17873749 ] Andriy Redko commented on CXF-8840: --- [~dmiro] Please check https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df > Introduce HTTP/2 Transport: client-side support using JDK's HttpClient > --- > > Key: CXF-8840 > URL: https://issues.apache.org/jira/browse/CXF-8840 > Project: CXF > Issue Type: Sub-task >Affects Versions: 4.0.0 >Reporter: Andriy Redko >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.6.0, 4.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8840) Introduce HTTP/2 Transport: client-side support using JDK's HttpClient
[ https://issues.apache.org/jira/browse/CXF-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8840: -- Affects Version/s: (was: 3.6.0) > Introduce HTTP/2 Transport: client-side support using JDK's HttpClient > --- > > Key: CXF-8840 > URL: https://issues.apache.org/jira/browse/CXF-8840 > Project: CXF > Issue Type: Sub-task >Affects Versions: 4.0.0 >Reporter: Andriy Redko >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.6.0, 4.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8840) Introduce HTTP/2 Transport: client-side support using JDK's HttpClient
[ https://issues.apache.org/jira/browse/CXF-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873742#comment-17873742 ] Andriy Redko commented on CXF-8840: --- [~dmiro] yes > Introduce HTTP/2 Transport: client-side support using JDK's HttpClient > --- > > Key: CXF-8840 > URL: https://issues.apache.org/jira/browse/CXF-8840 > Project: CXF > Issue Type: Sub-task >Affects Versions: 4.0.0, 3.6.0 >Reporter: Andriy Redko >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.6.0, 4.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873339#comment-17873339 ] Andriy Redko commented on CXF-8931: --- [~bodhione] sure, as an option, but would you mind please help with the reproducer? I am wondering why this case was working before differently, thank you. > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873285#comment-17873285 ] Andriy Redko commented on CXF-8931: --- [~bodhione] please check [https://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html#markSupported--] which states that mark() and reset() may or may not be supported > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9046) JAX-RS performance client should close response objects after calls.
[ https://issues.apache.org/jira/browse/CXF-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9046. --- Resolution: Fixed > JAX-RS performance client should close response objects after calls. > > > Key: CXF-9046 > URL: https://issues.apache.org/jira/browse/CXF-9046 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Assignee: Jamie Mark Goodyear >Priority: Minor > Fix For: 4.1.0 > > > JAX-RS performance client should close response objects after calls. > When the client does not specifically close the object, then it waits on GC > pass. > Under heavy load one can overwhelm the client port range. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9046) JAX-RS performance client should close response objects after calls.
[ https://issues.apache.org/jira/browse/CXF-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-9046: - Assignee: Jamie Mark Goodyear > JAX-RS performance client should close response objects after calls. > > > Key: CXF-9046 > URL: https://issues.apache.org/jira/browse/CXF-9046 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Assignee: Jamie Mark Goodyear >Priority: Minor > Fix For: 4.1.0 > > > JAX-RS performance client should close response objects after calls. > When the client does not specifically close the object, then it waits on GC > pass. > Under heavy load one can overwhelm the client port range. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873031#comment-17873031 ] Andriy Redko commented on CXF-8931: --- > Which RFCs are in play here, is it RFC 2616, 4743 ? https://datatracker.ietf.org/doc/html/rfc2616#section-4.4 > When you say 'will be using chunked transfer encoding at the moment', isn't > it that you have the stream in CXF and can calculate the outbound size or ? AFAIK, it is not always possible to iterate over the stream repeatedly (to calculate outbound size, and than to send it over). > This is a change from previous behavior so we need to understand what > direction CXF is going. Could you please share a reproducer / test case (in terms of what server accepts and what client sends) so we could troubleshoot the difference in behavior? Thank you. > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872975#comment-17872975 ] Andriy Redko edited comment on CXF-8931 at 8/12/24 4:00 PM: [~bodhione] [~jhack] so here is the thing with chunking (which applies to all clients): the chunked setting is a hint only. Even if chunked is false, `HttpClient` must use chunk coding if the entity content length is unknown (-1). In this regard, if the size of the payload is not known (InputStream, etc), the `HttpClient` will be using chunked transfer encoding at the moment. was (Author: reta): [~bodhione] [~jhack] so here is the thing with chunking (which applies to all clients): the chunked setting is a hint only. Even if chunked is false, `HttpClient` must use chunk coding if the entity content length is unknown (-1). In this regards, if the size of the payload is not known (InputStream, etc), the `HttpClient` will be using chunked transfer encoding at the moment. > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872975#comment-17872975 ] Andriy Redko commented on CXF-8931: --- [~bodhione] [~jhack] so here is the thing with chunking (which applies to all clients): the chunked setting is a hint only. Even if chunked is false, `HttpClient` must use chunk coding if the entity content length is unknown (-1). In this regards, if the size of the payload is not known (InputStream, etc), the `HttpClient` will be using chunked transfer encoding at the moment. > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-8931: - Assignee: Andriy Redko (was: Jim Ma) > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872733#comment-17872733 ] Andriy Redko commented on CXF-8931: --- [~ema] if you don't mind, I will take it, have a solution I think, thanks! > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8931: -- Fix Version/s: 4.1.0 3.6.5 4.0.6 > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8950) HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
[
https://issues.apache.org/jira/browse/CXF-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8950.
---
Resolution: Information Provided
> HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
> -
>
> Key: CXF-8950
> URL: https://issues.apache.org/jira/browse/CXF-8950
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Sebastian Violet
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.6.5, 4.0.6
>
> Attachments: CXF-HTTPClient-LargePayload.zip
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is the input stream is closed prematurely.
>
> [^CXF-HTTPClient-LargePayload.zip] , you will see that we are using
> {*}Response{*}, because we are interested in getting response status as well
> as the response headers. This fails with the following error:
> {code:java}
> Exception in thread "main" java.lang.RuntimeException: java.io.IOException:
> closed
> at LargeDataTester.main(LargeDataTester.java:89)
> Caused by: java.io.IOException: closed
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:448)
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:508)
> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:119)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientFilteredInputStream.read(HttpClientHTTPConduit.java:422)
> at
> java.base/java.io.SequenceInputStream.read(SequenceInputStream.java:197)
> at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:333)
> at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:376)
> at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:219)
> at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:173)
> at java.base/java.io.InputStreamReader.read(InputStreamReader.java:189)
> at java.base/java.io.Reader.read(Reader.java:265)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1610)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1589)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1384)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1153)
> at org.apache.commons.io.IOUtils.toString(IOUtils.java:3105)
> at LargeDataTester.main(LargeDataTester.java:84)
> Caused by: java.io.IOException: selector manager closed
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.selectorClosedException(HttpClientImpl.java:1061)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.closeSubscribers(HttpClientImpl.java:552)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:543)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1165)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1364)
> {code}
>
> {color:#FF}*You can execute the code like so:*{color}
> {code:java}
> mvn compile exec:exec{code}
> ℹ️ {*}Note{*}: You can do a diff between what works(Letting CXF deserialize
> the object response payload automatically), and the last commit(Using
> Response).
> {code:java}
> git diff HEAD^ HEAD {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9041) Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
[
https://issues.apache.org/jira/browse/CXF-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9041.
---
Resolution: Fixed
> Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
> -
>
> Key: CXF-9041
> URL: https://issues.apache.org/jira/browse/CXF-9041
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, Soap Binding, WS-* Components
>Affects Versions: 4.0.4
> Environment: OpenLiberty 24.0.0.6
> JDK 17 (IBM Semeru)
>Reporter: Benjamin Marwell
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
> Attachments: jaxb-no-fallback.png
>
>
> Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
> Excerpt from an IBM case:
> {quote}[..] the post-update problem is caused by their third-party Web
> Service implementation (Apache CXF 4.0). CXF had a similar issue with the XML
> Binding specification look up algorithm, which they addressed by hard coding
> their own dependency on the XML Binding Reference implementation. This is the
> code from JAXBUtils.java:
> {quote}
> {code:java}
> public static JAXBContext createContext(final Set> classes,
> final Map map)
> throws JAXBException {
> JAXBContext ctx = null;
> try {
> ctx = AccessController.doPrivileged(new
> PrivilegedExceptionAction() {
> public JAXBContext run() throws Exception {
> //This is a workaround for CXF-8675
> Class factoryClass =
> ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
> JAXBContextCache.class);
> Method m = factoryClass.getMethod("createContext",
> Class[].class, Map.class);
> Object context = m.invoke(null, classes.toArray(new
> Class[0]), map);
> return (JAXBContext) context;
> }
> });
> } catch (PrivilegedActionException e2) {
> if (e2.getException() instanceof JAXBException) {
> JAXBException ex = (JAXBException) e2.getException();
> throw ex;
> } else {
> throw new RuntimeException(e2.getException());
> }
> }
> return ctx;
> }
> {code}
> {quote}In the developers opinion, this was a terrible fix on Apache CXF's
> part, since they've introduced a hard dependency on a specific implementation
> of XML Binding, rather then allowing a user to provide their own
> implementation (which is how its always been in the past, and its how our
> xmlWS-4.0 feaeture is written).
> {quote}
> Confirmed by [~rmannibucau] (Regression):
> !jaxb-no-fallback.png|width=1005,height=428!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9044) Unable to configure CXF client for NTLM
[
https://issues.apache.org/jira/browse/CXF-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872482#comment-17872482
]
Andriy Redko commented on CXF-9044:
---
Hi Tom, are you using JAX-WS web services? If yes, you could pass credentials
using request context:
https://github.com/apache/cxf/blob/main/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyDigestAuthTest.java#L120
> Unable to configure CXF client for NTLM
> ---
>
> Key: CXF-9044
> URL: https://issues.apache.org/jira/browse/CXF-9044
> Project: CXF
> Issue Type: Task
>Reporter: Tom
>Priority: Trivial
>
> I am trying to use CXF version 4 client to consume a web service secured by
> NTLM. I found CXF-4525 which suggested to use http async client. However, now
> httpConduit is using
> CloseableHttpAsyncClient so it does not have option to set NT credentials
>
> I can use HTTP client to have NT Credential as follows
> CredentialsProvider credsProvider = new BasicCredentialsProvider();
> credsProvider.setCredentials(AuthScope.ANY,
> new NTCredentials("userbane", "password", "", "domain"));
> HttpClient client =
> HttpClientBuilder.create().setDefaultCredentialsProvider(credsProvider).build();
> HttpPost post = new HttpPost("the url");
> Is there a way to inject that HttpClient in CXF 4?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-9044) Unable to configure CXF client for NTLM
[
https://issues.apache.org/jira/browse/CXF-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872482#comment-17872482
]
Andriy Redko edited comment on CXF-9044 at 8/9/24 10:20 PM:
Hi [~tom2011] , are you using JAX-WS web services? If yes, you could pass
credentials using request context:
[https://github.com/apache/cxf/blob/main/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyDigestAuthTest.java#L120]
was (Author: reta):
Hi Tom, are you using JAX-WS web services? If yes, you could pass credentials
using request context:
https://github.com/apache/cxf/blob/main/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyDigestAuthTest.java#L120
> Unable to configure CXF client for NTLM
> ---
>
> Key: CXF-9044
> URL: https://issues.apache.org/jira/browse/CXF-9044
> Project: CXF
> Issue Type: Task
>Reporter: Tom
>Priority: Trivial
>
> I am trying to use CXF version 4 client to consume a web service secured by
> NTLM. I found CXF-4525 which suggested to use http async client. However, now
> httpConduit is using
> CloseableHttpAsyncClient so it does not have option to set NT credentials
>
> I can use HTTP client to have NT Credential as follows
> CredentialsProvider credsProvider = new BasicCredentialsProvider();
> credsProvider.setCredentials(AuthScope.ANY,
> new NTCredentials("userbane", "password", "", "domain"));
> HttpClient client =
> HttpClientBuilder.create().setDefaultCredentialsProvider(credsProvider).build();
> HttpPost post = new HttpPost("the url");
> Is there a way to inject that HttpClient in CXF 4?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9045) Enhance samples/performance/jax-rs to accept host values
[ https://issues.apache.org/jira/browse/CXF-9045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9045. --- Resolution: Fixed > Enhance samples/performance/jax-rs to accept host values > > > Key: CXF-9045 > URL: https://issues.apache.org/jira/browse/CXF-9045 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Priority: Trivial > Fix For: 4.1.0 > > > Enhance samples/performance/jax-rs to accept host values. > When running JAX-RS Client and Server on different hosts it would be nice to > not need to update the hard coded values. > Users should be able to pass -Dhost=some.value -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9045) Enhance samples/performance/jax-rs to accept host values
[ https://issues.apache.org/jira/browse/CXF-9045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9045: -- Fix Version/s: (was: 3.6.5) (was: 4.0.6) > Enhance samples/performance/jax-rs to accept host values > > > Key: CXF-9045 > URL: https://issues.apache.org/jira/browse/CXF-9045 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Priority: Trivial > Fix For: 4.1.0 > > > Enhance samples/performance/jax-rs to accept host values. > When running JAX-RS Client and Server on different hosts it would be nice to > not need to update the hard coded values. > Users should be able to pass -Dhost=some.value -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9045) Enhance samples/performance/jax-rs to accept host values
[ https://issues.apache.org/jira/browse/CXF-9045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9045: -- Fix Version/s: 4.1.0 3.6.5 4.0.6 > Enhance samples/performance/jax-rs to accept host values > > > Key: CXF-9045 > URL: https://issues.apache.org/jira/browse/CXF-9045 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Priority: Trivial > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > Enhance samples/performance/jax-rs to accept host values. > When running JAX-RS Client and Server on different hosts it would be nice to > not need to update the hard coded values. > Users should be able to pass -Dhost=some.value -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 (https://in.relation.to/2024/08/01/orm-70-beta1/) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0-RC4)] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1]) was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0-RC4)] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 (https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1) > Support Jakar
[jira] [Updated] (CXF-9042) Several unit tests are non-idempotent
[ https://issues.apache.org/jira/browse/CXF-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9042: -- Summary: Several unit tests are non-idempotent (was: Several unit tests are non-idempotent. Will open a PR to fix them) > Several unit tests are non-idempotent > - > > Key: CXF-9042 > URL: https://issues.apache.org/jira/browse/CXF-9042 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.9, 4.0.5, 3.6.4 >Reporter: Kaiyao Ke >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > - > org.apache.cxf.management.InstrumentationManagerTest#testWorkQueueInstrumentation > - > org.apache.cxf.sts.operation.ValidateJWTTransformationTest#testJWTToSAMLTransformationRealm > - > org.apache.cxf.systest.dispatch.DispatchClientServerTest#testJAXBObjectPAYLOADWithFeature -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9042) Several unit tests are non-idempotent
[ https://issues.apache.org/jira/browse/CXF-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9042. --- Resolution: Fixed > Several unit tests are non-idempotent > - > > Key: CXF-9042 > URL: https://issues.apache.org/jira/browse/CXF-9042 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.9, 4.0.5, 3.6.4 >Reporter: Kaiyao Ke >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > - > org.apache.cxf.management.InstrumentationManagerTest#testWorkQueueInstrumentation > - > org.apache.cxf.sts.operation.ValidateJWTTransformationTest#testJWTToSAMLTransformationRealm > - > org.apache.cxf.systest.dispatch.DispatchClientServerTest#testJAXBObjectPAYLOADWithFeature -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9042) Several unit tests are non-idempotent. Will open a PR to fix them
[ https://issues.apache.org/jira/browse/CXF-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9042: -- Fix Version/s: 4.1.0 3.5.10 3.6.5 4.0.6 > Several unit tests are non-idempotent. Will open a PR to fix them > - > > Key: CXF-9042 > URL: https://issues.apache.org/jira/browse/CXF-9042 > Project: CXF > Issue Type: Bug >Reporter: Kaiyao Ke >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > - > org.apache.cxf.management.InstrumentationManagerTest#testWorkQueueInstrumentation > - > org.apache.cxf.sts.operation.ValidateJWTTransformationTest#testJWTToSAMLTransformationRealm > - > org.apache.cxf.systest.dispatch.DispatchClientServerTest#testJAXBObjectPAYLOADWithFeature -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9042) Several unit tests are non-idempotent. Will open a PR to fix them
[ https://issues.apache.org/jira/browse/CXF-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9042: -- Affects Version/s: 3.6.4 4.0.5 3.5.9 > Several unit tests are non-idempotent. Will open a PR to fix them > - > > Key: CXF-9042 > URL: https://issues.apache.org/jira/browse/CXF-9042 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.9, 4.0.5, 3.6.4 >Reporter: Kaiyao Ke >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > - > org.apache.cxf.management.InstrumentationManagerTest#testWorkQueueInstrumentation > - > org.apache.cxf.sts.operation.ValidateJWTTransformationTest#testJWTToSAMLTransformationRealm > - > org.apache.cxf.systest.dispatch.DispatchClientServerTest#testJAXBObjectPAYLOADWithFeature -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9041) Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
[
https://issues.apache.org/jira/browse/CXF-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-9041:
-
Assignee: Andriy Redko
> Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
> -
>
> Key: CXF-9041
> URL: https://issues.apache.org/jira/browse/CXF-9041
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, Soap Binding, WS-* Components
>Affects Versions: 4.0.4
> Environment: OpenLiberty 24.0.0.6
> JDK 17 (IBM Semeru)
>Reporter: Benjamin Marwell
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
> Attachments: jaxb-no-fallback.png
>
>
> Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
> Excerpt from an IBM case:
> {quote}[..] the post-update problem is caused by their third-party Web
> Service implementation (Apache CXF 4.0). CXF had a similar issue with the XML
> Binding specification look up algorithm, which they addressed by hard coding
> their own dependency on the XML Binding Reference implementation. This is the
> code from JAXBUtils.java:
> {quote}
> {code:java}
> public static JAXBContext createContext(final Set> classes,
> final Map map)
> throws JAXBException {
> JAXBContext ctx = null;
> try {
> ctx = AccessController.doPrivileged(new
> PrivilegedExceptionAction() {
> public JAXBContext run() throws Exception {
> //This is a workaround for CXF-8675
> Class factoryClass =
> ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
> JAXBContextCache.class);
> Method m = factoryClass.getMethod("createContext",
> Class[].class, Map.class);
> Object context = m.invoke(null, classes.toArray(new
> Class[0]), map);
> return (JAXBContext) context;
> }
> });
> } catch (PrivilegedActionException e2) {
> if (e2.getException() instanceof JAXBException) {
> JAXBException ex = (JAXBException) e2.getException();
> throw ex;
> } else {
> throw new RuntimeException(e2.getException());
> }
> }
> return ctx;
> }
> {code}
> {quote}In the developers opinion, this was a terrible fix on Apache CXF's
> part, since they've introduced a hard dependency on a specific implementation
> of XML Binding, rather then allowing a user to provide their own
> implementation (which is how its always been in the past, and its how our
> xmlWS-4.0 feaeture is written).
> {quote}
> Confirmed by [~rmannibucau] (Regression):
> !jaxb-no-fallback.png|width=1005,height=428!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CXF-9043) CXF 4.1.0 official release plan query as Jetty12 integration is blocked due to unsupported 4.0.x version
[ https://issues.apache.org/jira/browse/CXF-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko closed CXF-9043. - Resolution: Not A Problem [~bitan] we have an issue which consolidates the work remaining (see please https://issues.apache.org/jira/browse/CXF-8671), please feel free to contribute to accelerate the completion. Thank you. > CXF 4.1.0 official release plan query as Jetty12 integration is blocked due > to unsupported 4.0.x version > > > Key: CXF-9043 > URL: https://issues.apache.org/jira/browse/CXF-9043 > Project: CXF > Issue Type: Improvement >Reporter: Bitan Paul >Priority: Major > > CXF 4.0.x version does not support Jetty12 but CXF 4.1.0-SNAPSHOT works as > expected. As still the official release is not provided for 4.1.0 version, > Jetty 12 integration is blocked. Could you please provide an update on when > is the plan to release CXF 4.1.0 officially? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8671) Support Jakarta EE 10
[ https://issues.apache.org/jira/browse/CXF-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8671: -- Description: Support Jakarta EE 10 Jakarta EE 10 has Landed - [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] [https://jakarta.ee/release/10/] [https://www.infoq.com/news/2023/01/glassfish-delivers-support-jdk17/] Specs ([https://repo1.maven.org/maven2/jakarta/platform/jakartaee-api-parent/10.0.0/jakartaee-api-parent-10.0.0.pom):] * Jakarta Activation 2.1* * Jakarta Authentication 3.0* * Jakarta Authorization 2.1* * Jakarta Batch 2.1* * Jakarta Bean Validation 3.0 * Jakarta Common Annotations 2.1* * Jakarta Concurrency 3.0* * Jakarta Connectors 2.1* * Jakarta Contexts and Dependency Injection 4.0* * Jakarta Debugging Support for Other Languages 2.0 * Jakarta Dependency Injection 2.0 * Jakarta Enterprise Beans 4.0 (except for Jakarta Enterprise Beans entity beans and associated Jakarta Enterprise Beans QL, and embedded container, which have been made removed) * Jakarta Expression Language 5.0* * Jakarta Interceptors 2.1* * Jakarta JSON Processing 2.1* * Jakarta JSON Binding 3.0* * Jakarta Mail 2.1* * Jakarta Managed Beans 2.0 * Jakarta Messaging 3.1* * Jakarta Persistence 3.1* * Jakarta RESTful Web Services 3.1* * Jakarta Security 3.0* * Jakarta Servlet 6.0* * Jakarta Server Faces 4.0* * Jakarta Server Pages 3.1* * Jakarta Standard Tag Library 3.0* * Jakarta Transactions 2.0 * Jakarta WebSocket 2.1* * Jakarta Enterprise Beans 3.2 and earlier entity beans and associated Jakarta Enterprise Beans QL * Jakarta Enterprise Beans 2.x API group * Jakarta Enterprise Web Services 2.0 * Jakarta SOAP with Attachments 3.0* * Jakarta XML Web Services 4.0* * Jakarta XML Binding 4.0* Rest Client TCK update: - [https://github.com/eclipse/microprofile-rest-client/pull/352] Updates required: - *[DONE]* Brave 6 - *[DONE]* OpenTelemetry 1.37.0+ - Apache Tika 3.0.0 ([https://github.com/apache/tika/releases/tag/3.0.0-BETA)] - *[DONE]* UnboundID LDAP SDK for Java 7.0.0 ([https://github.com/pingidentity/ldapsdk/releases/tag/7.0.0]) - *[DONE]* Undertow 2.3.x - *[DONE]* Jetty 12 ([https://github.com/eclipse/jetty.project/releases/tag/jetty-12.0.0.beta0]) - *[DONE]* Hibernate Validator 8 ([https://hibernate.org/validator/releases/8.0/)] - *[DONE]* Hibernate 6.4 ([https://in.relation.to/2023/11/23/orm-640-final/|https://in.relation.to/2023/08/31/orm-630/]) - *[DONE]* Weld 5 ([https://weld.cdi-spec.org/news/2022/04/29/weld-500Final/]) - *[DONE]* Spring Boot 3.3 ([https://github.com/spring-projects/spring-boot/releases/tag/v3.3.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.1.0]) - *[DONE]* Spring Security 6.3 ([https://github.com/spring-projects/spring-security/releases/tag/6.3.0|https://github.com/spring-projects/spring-security/releases/tag/6.1.0]) - *[DONE]* Micrometer 1.13 ([https://github.com/micrometer-metrics/micrometer/releases/tag/v1.13.1|https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0-M1]) - *[DONE]* Micrometer Tracing 1.3 ([https://github.com/micrometer-metrics/tracing/releases/tag/v1.3.1)|https://github.com/micrometer-metrics/tracing/releases/tag/v1.1.4)] - *[DONE]* Spring LDAP 3.2 ([https://github.com/spring-projects/spring-ldap/releases/tag/3.2.0)|https://github.com/spring-projects/spring-ldap/releases/tag/3.1.0)] Microprofile 6.0 ([https://download.eclipse.org/microprofile/microprofile-6.0/microprofile-spec-6.0.html),] aligned with JakartaEE 10 core profile: - *[DONE]* Microprofile OpenAPI 3.1 ([https://github.com/eclipse/microprofile-open-api/releases/tag/3.1]) - *[DONE]* Microprofile Config 3.1 ([https://github.com/eclipse/microprofile-config/releases/tag/3.1]) - *[DONE]* Angus Mail ([https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.1]) - [https://github.com/arquillian/arquillian-container-weld/releases/tag/3.0.2.Final] Migration Guide: [https://cwiki.apache.org/confluence/display/CXF20DOC/4.1+Migration+Guide] was: Support Jakarta EE 10 Jakarta EE 10 has Landed - [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] [https://jakarta.ee/release/10/] [https://www.infoq.com/news/2023/01/glassfish-delivers-support-jdk17/] Specs ([https://repo1.maven.org/maven2/jakarta/platform/jakartaee-api-parent/10.0.0/jakartaee-api-parent-10.0.0.pom):] * Jakarta Activation 2.1* * Jakarta Authentication 3.0* * Jakarta Authorization 2.1* * Jakarta Batch 2.1* * Jakarta Bean Validation 3.0 * Jakarta Common Annotations 2.1* * Jakarta Concurrency 3.0* * Jakarta Connectors 2.1* * Jakarta Contexts and Dependency Injection 4.0* * Jakarta Debugging Support for Other Languages 2.0 * Jakarta Dependency Injection 2.0 * Jakarta Enterprise Beans 4.0 (except for Jakarta Enterprise Beans entity beans
[jira] [Resolved] (CXF-9037) NPE when using com.ctc.wstx.returnNullForDefaultNamespace=true
[
https://issues.apache.org/jira/browse/CXF-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9037.
---
Resolution: Fixed
> NPE when using com.ctc.wstx.returnNullForDefaultNamespace=true
> --
>
> Key: CXF-9037
> URL: https://issues.apache.org/jira/browse/CXF-9037
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Gordon Freeman
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.10, 3.6.5, 4.0.6
>
> Attachments: xmlTest.zip
>
>
> I am using custom out interceptor, which make xsl transformation to serialize
> some elements as CDATA, my code was inspired by
> org.apache.cxf.feature.transform.XSLTOutInterceptor.
> But if I set property com.ctc.wstx.returnNullForDefaultNamespace=true, the
> I've got an NPE. This property is required to fix some other issues with xml
> generation (without it I've got empty namespaces xmlns="" in some cases).
> The code bellow is the minimum example of NPE, using
> org.apache.cxf.staxutils.StaxSource.
>
> {code:java}
> Exception in thread "main" java.lang.NullPointerException: Cannot invoke
> "String.equals(Object)" because "prefix" is null
> at
> net.sf.saxon.event.ReceivingContentHandler.startPrefixMapping(ReceivingContentHandler.java:300)
>
> at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:145)
> at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:259)
> at
> net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:192)
> at net.sf.saxon.event.Sender.send(Sender.java:104)
> at
> net.sf.saxon.jaxp.IdentityTransformer.transform(IdentityTransformer.java:364)
> {code}
> {code:java}
> package test;
> import com.ctc.wstx.stax.WstxInputFactory;
> import org.apache.cxf.staxutils.StaxSource;
> import javax.xml.transform.OutputKeys;
> import javax.xml.transform.Source;
> import javax.xml.transform.Transformer;
> import javax.xml.transform.TransformerFactory;
> import javax.xml.transform.stax.StAXSource;
> import javax.xml.transform.stream.StreamResult;
> import java.io.ByteArrayInputStream;
> import java.io.StringWriter;
> import java.nio.charset.StandardCharsets;
> public class NpeTest
> {
> public static void main(String[] args) throws Exception
> {
> String bodyXml = "\n" +
> " xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\";>\n" +
> " \n" +
> "http://test.com/test\";>\n" +
> "<\n" +
> "\n" +
> " \n" +
> "\n";
> System.setProperty("com.ctc.wstx.returnNullForDefaultNamespace",
> "true");
> WstxInputFactory factory = new WstxInputFactory();
> Source beforeSource = new
> StaxSource(factory.createXMLStreamReader(new
> ByteArrayInputStream(bodyXml.getBytes(StandardCharsets.UTF_8;
> //Source beforeSource = new
> StAXSource(factory.createXMLStreamReader(new
> ByteArrayInputStream(bodyXml.getBytes(StandardCharsets.UTF_8;
> System.out.println(save(beforeSource));
> }
> public static String save(Source beforeSource) throws Exception
> {
> StringWriter writer = new StringWriter();
> StreamResult result = new StreamResult(writer);
> TransformerFactory tf = TransformerFactory.newInstance();
> Transformer transformer = tf.newTransformer();
> transformer.setOutputProperty(OutputKeys.INDENT, "yes");
> transformer.setOutputProperty(OutputKeys.STANDALONE, "yes");
> transformer.setOutputProperty(OutputKeys.CDATA_SECTION_ELEMENTS,
> "Q{http://test.com/test}reqBody";);
>
> transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount";,
> "4");
> transformer.transform(beforeSource, result);
> return writer.toString();
> }
> }
> {code}
> The stacktrace from my project is:
> {code:java}
> java.lang.NullPointerException
> at
> net.sf.saxon.event.ReceivingContentHandler.startPrefixMapping(ReceivingContentHandler.java:301)
> at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:145)
> at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:259)
> at
> net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:190)
> at net.sf.saxon.event.Sender.send(Sender.java:105)
> at
> net.sf.saxon.jaxp.IdentityTransformer.transform(IdentityTransformer.java:364)
> at
> org.apache.cxf.feature.transform.XSLTUtils.transform(XSLTUtils.java:57)
> at
> org.apache.cxf.feature.transform.XSLTOutInterceptor$XSLTCachedOutputStreamCallback.onClose(XSLTOutInterceptor.java:165)
> at
> org.apache.cxf.io.CachedO
[jira] [Updated] (CXF-9041) Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
[
https://issues.apache.org/jira/browse/CXF-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9041:
--
Fix Version/s: 4.1.0
> Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
> -
>
> Key: CXF-9041
> URL: https://issues.apache.org/jira/browse/CXF-9041
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, Soap Binding, WS-* Components
>Affects Versions: 4.0.4
> Environment: OpenLiberty 24.0.0.6
> JDK 17 (IBM Semeru)
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
> Attachments: jaxb-no-fallback.png
>
>
> Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
> Excerpt from an IBM case:
> {quote}[..] the post-update problem is caused by their third-party Web
> Service implementation (Apache CXF 4.0). CXF had a similar issue with the XML
> Binding specification look up algorithm, which they addressed by hard coding
> their own dependency on the XML Binding Reference implementation. This is the
> code from JAXBUtils.java:
> {quote}
> {code:java}
> public static JAXBContext createContext(final Set> classes,
> final Map map)
> throws JAXBException {
> JAXBContext ctx = null;
> try {
> ctx = AccessController.doPrivileged(new
> PrivilegedExceptionAction() {
> public JAXBContext run() throws Exception {
> //This is a workaround for CXF-8675
> Class factoryClass =
> ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
> JAXBContextCache.class);
> Method m = factoryClass.getMethod("createContext",
> Class[].class, Map.class);
> Object context = m.invoke(null, classes.toArray(new
> Class[0]), map);
> return (JAXBContext) context;
> }
> });
> } catch (PrivilegedActionException e2) {
> if (e2.getException() instanceof JAXBException) {
> JAXBException ex = (JAXBException) e2.getException();
> throw ex;
> } else {
> throw new RuntimeException(e2.getException());
> }
> }
> return ctx;
> }
> {code}
> {quote}In the developers opinion, this was a terrible fix on Apache CXF's
> part, since they've introduced a hard dependency on a specific implementation
> of XML Binding, rather then allowing a user to provide their own
> implementation (which is how its always been in the past, and its how our
> xmlWS-4.0 feaeture is written).
> {quote}
> Confirmed by [~rmannibucau] (Regression):
> !jaxb-no-fallback.png|width=1005,height=428!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9041) Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
[
https://issues.apache.org/jira/browse/CXF-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9041:
--
Priority: Major (was: Critical)
> Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
> -
>
> Key: CXF-9041
> URL: https://issues.apache.org/jira/browse/CXF-9041
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, Soap Binding, WS-* Components
>Affects Versions: 4.0.4
> Environment: OpenLiberty 24.0.0.6
> JDK 17 (IBM Semeru)
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: 4.0.6
>
> Attachments: jaxb-no-fallback.png
>
>
> Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
> Excerpt from an IBM case:
> {quote}[..] the post-update problem is caused by their third-party Web
> Service implementation (Apache CXF 4.0). CXF had a similar issue with the XML
> Binding specification look up algorithm, which they addressed by hard coding
> their own dependency on the XML Binding Reference implementation. This is the
> code from JAXBUtils.java:
> {quote}
> {code:java}
> public static JAXBContext createContext(final Set> classes,
> final Map map)
> throws JAXBException {
> JAXBContext ctx = null;
> try {
> ctx = AccessController.doPrivileged(new
> PrivilegedExceptionAction() {
> public JAXBContext run() throws Exception {
> //This is a workaround for CXF-8675
> Class factoryClass =
> ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
> JAXBContextCache.class);
> Method m = factoryClass.getMethod("createContext",
> Class[].class, Map.class);
> Object context = m.invoke(null, classes.toArray(new
> Class[0]), map);
> return (JAXBContext) context;
> }
> });
> } catch (PrivilegedActionException e2) {
> if (e2.getException() instanceof JAXBException) {
> JAXBException ex = (JAXBException) e2.getException();
> throw ex;
> } else {
> throw new RuntimeException(e2.getException());
> }
> }
> return ctx;
> }
> {code}
> {quote}In the developers opinion, this was a terrible fix on Apache CXF's
> part, since they've introduced a hard dependency on a specific implementation
> of XML Binding, rather then allowing a user to provide their own
> implementation (which is how its always been in the past, and its how our
> xmlWS-4.0 feaeture is written).
> {quote}
> Confirmed by [~rmannibucau] (Regression):
> !jaxb-no-fallback.png|width=1005,height=428!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9041) Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
[
https://issues.apache.org/jira/browse/CXF-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9041:
--
Affects Version/s: 4.0.4
> Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
> -
>
> Key: CXF-9041
> URL: https://issues.apache.org/jira/browse/CXF-9041
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, Soap Binding, WS-* Components
>Affects Versions: 4.0.4
> Environment: OpenLiberty 24.0.0.6
> JDK 17 (IBM Semeru)
>Reporter: Benjamin Marwell
>Priority: Critical
> Attachments: jaxb-no-fallback.png
>
>
> Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
> Excerpt from an IBM case:
> {quote}[..] the post-update problem is caused by their third-party Web
> Service implementation (Apache CXF 4.0). CXF had a similar issue with the XML
> Binding specification look up algorithm, which they addressed by hard coding
> their own dependency on the XML Binding Reference implementation. This is the
> code from JAXBUtils.java:
> {quote}
> {code:java}
> public static JAXBContext createContext(final Set> classes,
> final Map map)
> throws JAXBException {
> JAXBContext ctx = null;
> try {
> ctx = AccessController.doPrivileged(new
> PrivilegedExceptionAction() {
> public JAXBContext run() throws Exception {
> //This is a workaround for CXF-8675
> Class factoryClass =
> ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
> JAXBContextCache.class);
> Method m = factoryClass.getMethod("createContext",
> Class[].class, Map.class);
> Object context = m.invoke(null, classes.toArray(new
> Class[0]), map);
> return (JAXBContext) context;
> }
> });
> } catch (PrivilegedActionException e2) {
> if (e2.getException() instanceof JAXBException) {
> JAXBException ex = (JAXBException) e2.getException();
> throw ex;
> } else {
> throw new RuntimeException(e2.getException());
> }
> }
> return ctx;
> }
> {code}
> {quote}In the developers opinion, this was a terrible fix on Apache CXF's
> part, since they've introduced a hard dependency on a specific implementation
> of XML Binding, rather then allowing a user to provide their own
> implementation (which is how its always been in the past, and its how our
> xmlWS-4.0 feaeture is written).
> {quote}
> Confirmed by [~rmannibucau] (Regression):
> !jaxb-no-fallback.png|width=1005,height=428!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9041) Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
[
https://issues.apache.org/jira/browse/CXF-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9041:
--
Fix Version/s: 4.0.6
> Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
> -
>
> Key: CXF-9041
> URL: https://issues.apache.org/jira/browse/CXF-9041
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, Soap Binding, WS-* Components
>Affects Versions: 4.0.4
> Environment: OpenLiberty 24.0.0.6
> JDK 17 (IBM Semeru)
>Reporter: Benjamin Marwell
>Priority: Critical
> Fix For: 4.0.6
>
> Attachments: jaxb-no-fallback.png
>
>
> Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
> Excerpt from an IBM case:
> {quote}[..] the post-update problem is caused by their third-party Web
> Service implementation (Apache CXF 4.0). CXF had a similar issue with the XML
> Binding specification look up algorithm, which they addressed by hard coding
> their own dependency on the XML Binding Reference implementation. This is the
> code from JAXBUtils.java:
> {quote}
> {code:java}
> public static JAXBContext createContext(final Set> classes,
> final Map map)
> throws JAXBException {
> JAXBContext ctx = null;
> try {
> ctx = AccessController.doPrivileged(new
> PrivilegedExceptionAction() {
> public JAXBContext run() throws Exception {
> //This is a workaround for CXF-8675
> Class factoryClass =
> ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
> JAXBContextCache.class);
> Method m = factoryClass.getMethod("createContext",
> Class[].class, Map.class);
> Object context = m.invoke(null, classes.toArray(new
> Class[0]), map);
> return (JAXBContext) context;
> }
> });
> } catch (PrivilegedActionException e2) {
> if (e2.getException() instanceof JAXBException) {
> JAXBException ex = (JAXBException) e2.getException();
> throw ex;
> } else {
> throw new RuntimeException(e2.getException());
> }
> }
> return ctx;
> }
> {code}
> {quote}In the developers opinion, this was a terrible fix on Apache CXF's
> part, since they've introduced a hard dependency on a specific implementation
> of XML Binding, rather then allowing a user to provide their own
> implementation (which is how its always been in the past, and its how our
> xmlWS-4.0 feaeture is written).
> {quote}
> Confirmed by [~rmannibucau] (Regression):
> !jaxb-no-fallback.png|width=1005,height=428!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866861#comment-17866861 ] Andriy Redko commented on CXF-8629: --- [~bocamel] I think this very related problem: it seems like the client sends non-chunked request (this is expected) but the server replies with chunked response (I believe `AllowChunking` has no effect here since this is driven by server). The Apache HttpClient5 conduit does not support the response chunking yet. > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.10, 3.6.5, 4.0.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9031) Upgrade to Netty 4.2
[ https://issues.apache.org/jira/browse/CXF-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9031: -- Description: [https://github.com/netty/netty/releases/tag/netty-4.2.0.Alpha1] https://github.com/netty/netty/issues/14010 was:https://github.com/netty/netty/releases/tag/netty-4.2.0.Alpha1 > Upgrade to Netty 4.2 > > > Key: CXF-9031 > URL: https://issues.apache.org/jira/browse/CXF-9031 > Project: CXF > Issue Type: Task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > [https://github.com/netty/netty/releases/tag/netty-4.2.0.Alpha1] > https://github.com/netty/netty/issues/14010 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9031) Upgrade to Netty 4.2
[ https://issues.apache.org/jira/browse/CXF-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9031: -- Description: [https://github.com/netty/netty/releases/tag/netty-4.2.0.Alpha1] [https://github.com/netty/netty/issues/14010 |https://github.com/netty/netty/issues/14010](io_uring into 4.2) was: [https://github.com/netty/netty/releases/tag/netty-4.2.0.Alpha1] https://github.com/netty/netty/issues/14010 > Upgrade to Netty 4.2 > > > Key: CXF-9031 > URL: https://issues.apache.org/jira/browse/CXF-9031 > Project: CXF > Issue Type: Task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > [https://github.com/netty/netty/releases/tag/netty-4.2.0.Alpha1] > [https://github.com/netty/netty/issues/14010 > |https://github.com/netty/netty/issues/14010](io_uring into 4.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
