[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]) 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/) 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]) > Support Jakarta EE 11 > - > > Key: CXF-8828 > URL: https://issues.apache.org/jira/browse/CXF-8828 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > 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/)] >
[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/) 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]) 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/]) 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]) > Support Jakarta EE 11 > - > > Key: CXF-8828 > URL: https://issues.apache.org/jira/browse/CXF-8828 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > 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
[jira] [Commented] (CXF-8671) Support Jakarta EE 10
[
https://issues.apache.org/jira/browse/CXF-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853299#comment-17853299
]
Andriy Redko commented on CXF-8671:
---
[~ruslan.hryn] no ETA for release but you could try snapshots already
> Support Jakarta EE 10
> -
>
> Key: CXF-8671
> URL: https://issues.apache.org/jira/browse/CXF-8671
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0
>
>
> 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:
> - Brave 6
> - 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])
> - 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.2
> ([https://github.com/spring-projects/spring-boot/releases/tag/v3.2.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.1.0])
> - *[DONE]* Spring Security 6.2
> ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0])
> - *[DONE]* Micrometer 1.12
> ([https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0|https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0-M1])
> - {*}[DONE]{*}Micrometer Tracing 1.2
> ([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:
> - Microprofile OpenAPI 3.1
> ([https://github.com/eclipse/microprofile-open-api/releases/tag/3.1])
> - Microprofile Config 3.1
> ([https://github.com/eclipse/microprofile-config/releases/tag/3.1])
> - 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]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (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 resolved CXFXJC-47.
Resolution: Fixed
> 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.0.1, 4.1.0, 3.3.4
>
>
> 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] [Updated] (CXF-8976) Update to OpenTelemetry v1.39.0
[
https://issues.apache.org/jira/browse/CXF-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8976:
--
Summary: Update to OpenTelemetry v1.39.0 (was: Update to OpenTelemetry
v1.38.0)
> Update to OpenTelemetry v1.39.0
> ---
>
> Key: CXF-8976
> URL: https://issues.apache.org/jira/browse/CXF-8976
> Project: CXF
> Issue Type: Improvement
> Components: Tracing
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0
>
>
> The OpenTelemetry v1.35.0 SDKs switched to Brave 6:
> {noformat}
> "io.zipkin.brave:brave-bom:6.0.0",
> "io.zipkin.reporter2:zipkin-reporter-bom:3.2.1", {noformat}
--
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: 3.3.4
(was: 3.3.3)
> 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.0.1, 4.1.0, 3.3.4
>
>
> 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] [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: 3.3.3
> 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: 3.3.3, 4.0.1, 4.1.0
>
>
> 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] [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:
---
Description:
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.
> 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.0.1, 4.1.0
>
>
> 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] [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:
---
Summary: XJC DefaultValue plugin uses JAXBElement that does not have a
default constructor (was: XJC DefaultValue plugin uses JAXBElement that does
not have a default constructor.)
> 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.0.1, 4.1.0
>
>
> 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] [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: --- Affects Version/s: 4.0.0 > 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 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXFXJC-47) XJC DefaultValue plugin uses JAXBElement that does not have a default constructor.
Andriy Redko created CXFXJC-47: -- Summary: 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 Reporter: Andriy Redko Assignee: Andriy Redko -- 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.1.0 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.0.1, 4.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9007) NullPointerException in XMLStreamDataWriter.writeNode
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852604#comment-17852604
]
Andriy Redko commented on CXF-9007:
---
Hi [~maghol] , thanks a lot for confirming, I think we could go with this small
fix for now, thanks again!
> NullPointerException in XMLStreamDataWriter.writeNode
> -
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Magnus Holm
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.5
>
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5.
> We've had this issue on 4.0.3 and 4.0.4. We might've had it on previous
> versions as well, but I don't have build history going back that far.
> JDK versions: Corretto 17 (17.0.8-amzn), Zulu 17 (17.0.10-zulu) ++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9027) Update Performance benchmark pom values
[ https://issues.apache.org/jira/browse/CXF-9027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9027. --- Resolution: Fixed > Update Performance benchmark pom values > --- > > Key: CXF-9027 > URL: https://issues.apache.org/jira/browse/CXF-9027 > Project: CXF > Issue Type: Test > Components: Samples >Affects Versions: 4.1.0 >Reporter: Jamie Mark Goodyear >Priority: Trivial > Fix For: 4.1.0 > > > When using the profiles for client or server there may be build issues vs the > clientserver profile. > Remove from jaxrs pom maven.exec.plugin.version from client profile. > Update soap_http_doc_lit pom cxf-rt-transports-http-jetty entry to > project.version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9027) Update Performance benchmark pom values
[ https://issues.apache.org/jira/browse/CXF-9027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9027: -- Fix Version/s: 4.1.0 > Update Performance benchmark pom values > --- > > Key: CXF-9027 > URL: https://issues.apache.org/jira/browse/CXF-9027 > Project: CXF > Issue Type: Test > Components: Samples >Affects Versions: 4.1.0 >Reporter: Jamie Mark Goodyear >Priority: Trivial > Fix For: 4.1.0 > > > When using the profiles for client or server there may be build issues vs the > clientserver profile. > Remove from jaxrs pom maven.exec.plugin.version from client profile. > Update soap_http_doc_lit pom cxf-rt-transports-http-jetty entry to > project.version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9009.
---
Resolution: Fixed
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Julio J. Gomez Diaz
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4
>
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851835#comment-17851835
]
Andriy Redko commented on CXF-9009:
---
Hello [~juliojgd] , just merged it, sorry about that. Regarding the release(s),
no exact timelines as of today, but I think the releases may happen this month
(june)
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Julio J. Gomez Diaz
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4
>
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9016) Upgrade Spring-Framework to 5.3.34 in Apache-cxf
[
https://issues.apache.org/jira/browse/CXF-9016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851595#comment-17851595
]
Andriy Redko commented on CXF-9016:
---
No exact timelines as of today, but I think the releases may happen this month
(june)
> Upgrade Spring-Framework to 5.3.34 in Apache-cxf
>
>
> Key: CXF-9016
> URL: https://issues.apache.org/jira/browse/CXF-9016
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.5.5, 3.5.6, 3.5.7, 3.5.8, 3.6.3
>Reporter: Nikhil
>Priority: Major
> Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4
>
>
> We have a high severity security issue with spring-framework ::
> h2. Affected Spring Products and Versions
> Spring Framework
> * 6.1.0 - 6.1.5
> * 6.0.0 - 6.0.18
> * 5.3.0 - 5.3.33
> * Older, unsupported versions are also affected
>
> {*}Summary{*}: Applications that use UriComponentsBuilder in Spring Framework
> to parse an externally provided URL (e.g. through a query parameter) AND
> perform validation checks on the host of the parsed URL may be vulnerable to
> a open redirect [https://cwe.mitre.org/data/definitions/601.html] attack or
> to a SSRF attack if the URL is used after passing validation checks.
> This is the same as CVE-2024-22243
> [https://spring.io/security/cve-2024-22243] , but with different input.
>
> *Note:* This is the same as *CVE-2024-22259* and {*}CVE-2024-22243{*}, but
> with different input.
> –
> All these issues were fixed in Spring-Framework *5.3.34*
>
> *Could you please review and update Spring-Framework as needed in CXF package
> ?*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9026) Integrate Jacoco into Apache CXF builds to collect code coverage stats
[ https://issues.apache.org/jira/browse/CXF-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9026: -- Description: We have never used any code coverage tools and it is difficult to asses the gaps in tests. The suggestion is to integrate Jacoco into Apache CXF builds to collect code coverage stats > Integrate Jacoco into Apache CXF builds to collect code coverage stats > -- > > Key: CXF-9026 > URL: https://issues.apache.org/jira/browse/CXF-9026 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.5 > > > We have never used any code coverage tools and it is difficult to asses the > gaps in tests. The suggestion is to integrate Jacoco into Apache CXF builds > to collect code coverage stats -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9026) Integrate Jacoco into Apache CXF builds to collect code coverage stats
Andriy Redko created CXF-9026: - Summary: Integrate Jacoco into Apache CXF builds to collect code coverage stats Key: CXF-9026 URL: https://issues.apache.org/jira/browse/CXF-9026 Project: CXF Issue Type: Improvement Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.1.0, 4.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9016) Upgrade Spring-Framework to 5.3.34 in Apache-cxf
[
https://issues.apache.org/jira/browse/CXF-9016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9016:
--
Fix Version/s: 3.5.9
4.1.0
4.0.5
3.6.4
> Upgrade Spring-Framework to 5.3.34 in Apache-cxf
>
>
> Key: CXF-9016
> URL: https://issues.apache.org/jira/browse/CXF-9016
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.5.5, 3.5.6, 3.5.7, 3.5.8, 3.6.3
>Reporter: Nikhil
>Priority: Major
> Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4
>
>
> We have a high severity security issue with spring-framework ::
> h2. Affected Spring Products and Versions
> Spring Framework
> * 6.1.0 - 6.1.5
> * 6.0.0 - 6.0.18
> * 5.3.0 - 5.3.33
> * Older, unsupported versions are also affected
>
> {*}Summary{*}: Applications that use UriComponentsBuilder in Spring Framework
> to parse an externally provided URL (e.g. through a query parameter) AND
> perform validation checks on the host of the parsed URL may be vulnerable to
> a open redirect [https://cwe.mitre.org/data/definitions/601.html] attack or
> to a SSRF attack if the URL is used after passing validation checks.
> This is the same as CVE-2024-22243
> [https://spring.io/security/cve-2024-22243] , but with different input.
>
> *Note:* This is the same as *CVE-2024-22259* and {*}CVE-2024-22243{*}, but
> with different input.
> –
> All these issues were fixed in Spring-Framework *5.3.34*
>
> *Could you please review and update Spring-Framework as needed in CXF package
> ?*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9016) Upgrade Spring-Framework to 5.3.34 in Apache-cxf
[
https://issues.apache.org/jira/browse/CXF-9016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851059#comment-17851059
]
Andriy Redko commented on CXF-9016:
---
[~somasaninikhil] All upcoming releases will be bundled with the latest
versions, I have added a version labels to this issue to help you navigate,
thank you.
> Upgrade Spring-Framework to 5.3.34 in Apache-cxf
>
>
> Key: CXF-9016
> URL: https://issues.apache.org/jira/browse/CXF-9016
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.5.5, 3.5.6, 3.5.7, 3.5.8, 3.6.3
>Reporter: Nikhil
>Priority: Major
> Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4
>
>
> We have a high severity security issue with spring-framework ::
> h2. Affected Spring Products and Versions
> Spring Framework
> * 6.1.0 - 6.1.5
> * 6.0.0 - 6.0.18
> * 5.3.0 - 5.3.33
> * Older, unsupported versions are also affected
>
> {*}Summary{*}: Applications that use UriComponentsBuilder in Spring Framework
> to parse an externally provided URL (e.g. through a query parameter) AND
> perform validation checks on the host of the parsed URL may be vulnerable to
> a open redirect [https://cwe.mitre.org/data/definitions/601.html] attack or
> to a SSRF attack if the URL is used after passing validation checks.
> This is the same as CVE-2024-22243
> [https://spring.io/security/cve-2024-22243] , but with different input.
>
> *Note:* This is the same as *CVE-2024-22259* and {*}CVE-2024-22243{*}, but
> with different input.
> –
> All these issues were fixed in Spring-Framework *5.3.34*
>
> *Could you please review and update Spring-Framework as needed in CXF package
> ?*
--
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] * 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 Persistence 3.2 (https://jakarta.ee/specifications/persistence/3.2/), Jakarta Validation 3.1 (https://jakarta.ee/specifications/bean-validation/3.1/) and Jakarta WebSocket 2.2 (https://jakarta.ee/specifications/websocket/2.2/) 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]) was: Support Jakarta EE 11 (https://jakarta.ee/specifications/platform/11/) Minimum JDK requirement - JDK-17 Jakarta Interceptors 2.2* [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) 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]) > Support Jakarta EE 11 > - > > Key: CXF-8828 > URL: https://issues.apache.org/jira/browse/CXF-8828 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > 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] > * 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 Persistence 3.2 > (https://jakarta.ee/specifications/persistence/3.2/), Jakarta Validation 3.1 > (https://jakarta.ee/specifications/bean-validation/3.1/) and Jakarta > WebSocket 2.2 (https://jakarta.ee/specifications/websocket/2.2/) > 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]) -- 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/]) 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]) 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] * 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 Persistence 3.2 (https://jakarta.ee/specifications/persistence/3.2/), Jakarta Validation 3.1 (https://jakarta.ee/specifications/bean-validation/3.1/) and Jakarta WebSocket 2.2 (https://jakarta.ee/specifications/websocket/2.2/) 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]) > Support Jakarta EE 11 > - > > Key: CXF-8828 > URL: https://issues.apache.org/jira/browse/CXF-8828 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > 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/]) > 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]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9017) Regression in proxy-based restful client
[
https://issues.apache.org/jira/browse/CXF-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849716#comment-17849716
]
Andriy Redko commented on CXF-9017:
---
It seems like, thanks [~iiliev2] , I am closing it as a duplicate
> Regression in proxy-based restful client
>
>
> Key: CXF-9017
> URL: https://issues.apache.org/jira/browse/CXF-9017
> Project: CXF
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Critical
>
> The memory leak fix introduced in
> https://issues.apache.org/jira/browse/CXF-8946 breaks the way the
> ClientProxyImpl works. It passes its ClientConfiguration down to sub-proxies.
> When those sub-proxies get garbage collected, that configuration gets closed.
> One of the objects that are closed is AbstractConduitSelector -> conduits.
> After that, any newly created sub-proxies will have misconfigured clients.
> For example, we are configuring TLSClientParameters on the conduit of the
> root, which gets wiped out and therefore the new child clients can no longer
> connect.
> {code:java}
> API api = JAXRSClientFactory.create(endpoint, , getCxfProviders(),
> true); // root proxy
> configure(api);//add TLSClientParameters
> SomeResource s = api.getSomeResource(); // sub-proxy
>
>
> SomeOtherResource s2 = api.get(); //broken{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9017) Regression in proxy-based restful client
[
https://issues.apache.org/jira/browse/CXF-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9017.
---
Resolution: Duplicate
> Regression in proxy-based restful client
>
>
> Key: CXF-9017
> URL: https://issues.apache.org/jira/browse/CXF-9017
> Project: CXF
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Critical
>
> The memory leak fix introduced in
> https://issues.apache.org/jira/browse/CXF-8946 breaks the way the
> ClientProxyImpl works. It passes its ClientConfiguration down to sub-proxies.
> When those sub-proxies get garbage collected, that configuration gets closed.
> One of the objects that are closed is AbstractConduitSelector -> conduits.
> After that, any newly created sub-proxies will have misconfigured clients.
> For example, we are configuring TLSClientParameters on the conduit of the
> root, which gets wiped out and therefore the new child clients can no longer
> connect.
> {code:java}
> API api = JAXRSClientFactory.create(endpoint, , getCxfProviders(),
> true); // root proxy
> configure(api);//add TLSClientParameters
> SomeResource s = api.getSomeResource(); // sub-proxy
>
>
> SomeOtherResource s2 = api.get(); //broken{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9015) Typo in JsonMapObjectReaderWriter treats \h as a special character instead of \n
[ https://issues.apache.org/jira/browse/CXF-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9015. --- Resolution: Fixed > Typo in JsonMapObjectReaderWriter treats \h as a special character instead of > \n > > > Key: CXF-9015 > URL: https://issues.apache.org/jira/browse/CXF-9015 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.8, 3.6.3, 4.0.4 >Reporter: Craig Perkins >Priority: Minor > Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4 > > > The JsonMapObjectReaderWriter class maintains a list of > [ESCAPED_CHARS|https://github.com/apache/cxf/blob/main/rt/rs/extensions/json-basic/src/main/java/org/apache/cxf/jaxrs/json/basic/JsonMapObjectReaderWriter.java#L45-L56] > which includes special characters that need to be escaped like the newline > (`\n`) and tab (`\t`) characters. This list also includes `\h`, but I can't > find any links to official documentation about this character needing to be > escaped. > According to this [SO post|https://stackoverflow.com/a/27516892] which > details escaped characters in JSON, it does not include `\h` in this list. > Issue in OpenSearch where this issue is discussed: > [https://github.com/opensearch-project/security/issues/2531#issuecomment-2111309193] > > PR to address the issue with more details: > [https://github.com/apache/cxf/pull/1872] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9020) Websockets for the CXF Server Side
[ https://issues.apache.org/jira/browse/CXF-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9020. --- Resolution: Fixed > Websockets for the CXF Server Side > -- > > Key: CXF-9020 > URL: https://issues.apache.org/jira/browse/CXF-9020 > Project: CXF > Issue Type: Wish >Reporter: Mehmet Can Cömert >Assignee: Andriy Redko >Priority: Trivial > > I have seen on the documentation page, it is said Web Sockets are only > available on the 3.x Snapshot. > [https://cxf.apache.org/docs/websocket.html] > However with the Ticket: > https://issues.apache.org/jira/browse/CXF-5604 > I can see that it is already merged. > Is banner on documentation page outdated or Websockets not fully supported by > CXF? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9020) Websockets for the CXF Server Side
[ https://issues.apache.org/jira/browse/CXF-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849550#comment-17849550 ] Andriy Redko commented on CXF-9020: --- The documentation [1]has been updated. [1] https://cwiki.apache.org/confluence/display/CXF20DOC/WebSocket > Websockets for the CXF Server Side > -- > > Key: CXF-9020 > URL: https://issues.apache.org/jira/browse/CXF-9020 > Project: CXF > Issue Type: Wish >Reporter: Mehmet Can Cömert >Assignee: Andriy Redko >Priority: Trivial > > I have seen on the documentation page, it is said Web Sockets are only > available on the 3.x Snapshot. > [https://cxf.apache.org/docs/websocket.html] > However with the Ticket: > https://issues.apache.org/jira/browse/CXF-5604 > I can see that it is already merged. > Is banner on documentation page outdated or Websockets not fully supported by > CXF? -- 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 Jakarta Interceptors 2.2* [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) 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]) was: Support Jakarta EE 11 Minimum JDK requirement - JDK-17 Jakarta Interceptors 2.2* [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/]https://github.com/apache/cxf/pull/1889) 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]) > Support Jakarta EE 11 > - > > Key: CXF-8828 > URL: https://issues.apache.org/jira/browse/CXF-8828 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > Support Jakarta EE 11 (https://jakarta.ee/specifications/platform/11/) > Minimum JDK requirement - JDK-17 > > Jakarta Interceptors 2.2* > [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) > > 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]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9019) Increase unit test coverage on cxf-rt-frontend-jaxws jaxws spi package.
[ https://issues.apache.org/jira/browse/CXF-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9019. --- Resolution: Fixed > Increase unit test coverage on cxf-rt-frontend-jaxws jaxws spi package. > --- > > Key: CXF-9019 > URL: https://issues.apache.org/jira/browse/CXF-9019 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Minor > Fix For: 4.1.0, 4.0.5 > > > Existing unit test coverage for jaxws spi package is low (mostly focussed on > W3CEpr in providerImpl). I've written an exploratory patch to help increase > coverage to most methods in the package. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9019) Increase unit test coverage on cxf-rt-frontend-jaxws jaxws spi package.
[ https://issues.apache.org/jira/browse/CXF-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9019: -- Affects Version/s: 4.0.4 > Increase unit test coverage on cxf-rt-frontend-jaxws jaxws spi package. > --- > > Key: CXF-9019 > URL: https://issues.apache.org/jira/browse/CXF-9019 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Minor > Fix For: 4.1.0 > > > Existing unit test coverage for jaxws spi package is low (mostly focussed on > W3CEpr in providerImpl). I've written an exploratory patch to help increase > coverage to most methods in the package. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9019) Increase unit test coverage on cxf-rt-frontend-jaxws jaxws spi package.
[ https://issues.apache.org/jira/browse/CXF-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9019: -- Fix Version/s: 4.0.5 > Increase unit test coverage on cxf-rt-frontend-jaxws jaxws spi package. > --- > > Key: CXF-9019 > URL: https://issues.apache.org/jira/browse/CXF-9019 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Minor > Fix For: 4.1.0, 4.0.5 > > > Existing unit test coverage for jaxws spi package is low (mostly focussed on > W3CEpr in providerImpl). I've written an exploratory patch to help increase > coverage to most methods in the package. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9020) Websockets for the CXF Server Side
[ https://issues.apache.org/jira/browse/CXF-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-9020: - Assignee: Andriy Redko > Websockets for the CXF Server Side > -- > > Key: CXF-9020 > URL: https://issues.apache.org/jira/browse/CXF-9020 > Project: CXF > Issue Type: Wish >Reporter: Mehmet Can Cömert >Assignee: Andriy Redko >Priority: Trivial > > I have seen on the documentation page, it is said Web Sockets are only > available on the 3.x Snapshot. > [https://cxf.apache.org/docs/websocket.html] > However with the Ticket: > https://issues.apache.org/jira/browse/CXF-5604 > I can see that it is already merged. > Is banner on documentation page outdated or Websockets not fully supported by > CXF? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9020) Websockets for the CXF Server Side
[ https://issues.apache.org/jira/browse/CXF-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849271#comment-17849271 ] Andriy Redko commented on CXF-9020: --- Thanks for highlighting that, Websockets are fully supported by CXF (as per https://issues.apache.org/jira/browse/CXF-5604), the documentation will be updated shortly, thank you. > Websockets for the CXF Server Side > -- > > Key: CXF-9020 > URL: https://issues.apache.org/jira/browse/CXF-9020 > Project: CXF > Issue Type: Wish >Reporter: Mehmet Can Cömert >Priority: Trivial > > I have seen on the documentation page, it is said Web Sockets are only > available on the 3.x Snapshot. > [https://cxf.apache.org/docs/websocket.html] > However with the Ticket: > https://issues.apache.org/jira/browse/CXF-5604 > I can see that it is already merged. > Is banner on documentation page outdated or Websockets not fully supported by > CXF? -- 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 Minimum JDK requirement - JDK-17 Jakarta Interceptors 2.2* [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/]https://github.com/apache/cxf/pull/1889) 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]) was: Support Jakarta EE 11 Minimum JDK requirement - JDK-17 Jakarta Interceptors 2.2* 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]) > Support Jakarta EE 11 > - > > Key: CXF-8828 > URL: https://issues.apache.org/jira/browse/CXF-8828 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > Support Jakarta EE 11 > Minimum JDK requirement - JDK-17 > > Jakarta Interceptors 2.2* > [Jakarta Validation 3.1 > (|https://jakarta.ee/specifications/bean-validation/3.1/]https://github.com/apache/cxf/pull/1889) > > 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]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9007) NullPointerException in XMLStreamDataWriter.writeNode
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848413#comment-17848413
]
Andriy Redko commented on CXF-9007:
---
Thank you [~maghol] , looking forward to test cases.
> NullPointerException in XMLStreamDataWriter.writeNode
> -
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Magnus Holm
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.5
>
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5.
> We've had this issue on 4.0.3 and 4.0.4. We might've had it on previous
> versions as well, but I don't have build history going back that far.
> JDK versions: Corretto 17 (17.0.8-amzn), Zulu 17 (17.0.10-zulu) ++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9009:
--
Fix Version/s: 3.5.9
4.1.0
4.0.5
3.6.4
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Julio J. Gomez Diaz
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4
>
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9009:
--
Affects Version/s: 3.6.3
3.5.8
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Julio J. Gomez Diaz
>Assignee: Andriy Redko
>Priority: Major
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847413#comment-17847413
]
Andriy Redko commented on CXF-9009:
---
{noformat}
May 17, 2024 2:52:39 P.M. io.netty.channel.ChannelInitializer
exceptionCaughtWARNING: Failed to initialize a channel. Closing: [id:
0xe5e4c70d]java.lang.IllegalStateException: complete already:
DefaultChannelPromise@1876fa2c(success) at
io.netty.util.concurrent.DefaultPromise.setSuccess(DefaultPromise.java:100) at
io.netty.channel.DefaultChannelPromise.setSuccess(DefaultChannelPromise.java:78)
at
org.apache.cxf.transport.http.netty.client.NettyHttpClientPipelineFactory.initChannel(NettyHttpClientPipelineFactory.java:187)
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129) at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1130)
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
at
io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
at
io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
at
io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
at
io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
at
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569) at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833) {noformat}
For the record, this is the real cause of the issue.
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 4.0.4
>Reporter: Julio J. Gomez Diaz
>Assignee: Andriy Redko
>Priority: Major
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached
[jira] [Resolved] (CXF-9002) JAXRSMultithreadedClientTest test cases failing on IBM JDK.
[
https://issues.apache.org/jira/browse/CXF-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9002.
---
Resolution: Fixed
> JAXRSMultithreadedClientTest test cases failing on IBM JDK.
> ---
>
> Key: CXF-9002
> URL: https://issues.apache.org/jira/browse/CXF-9002
> Project: CXF
> Issue Type: Test
> Components: JAX-RS
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
>
> JAXRSMultithreadedClientTest test cases failing on IBM JDK (Semeru 17).
> There is a JAXRS system test failure for {{JAXRSMultithreadedClientTest}}
> test cases:
> JAXRSMultithreadedClientTest.testStatefulWebClientThreadLocalWithCopy
> JAXRSMultithreadedClientTest.testStatefulWebClientWithCopy
> JAXRSMultithreadedClientTest.testThreadSafeProxyWithCopy
> The commonality between these tests are \{{threadSafe }}is set to false,
> which triggers a copy of existing client with WebClient.fromClient.
> The error traces contains the following shape:
> {code:java}
> Exception in thread "pool-12-thread-2" java.lang.AssertionError:
> WebClientWorker thread failed for 10,value10 at
> org.junit.Assert.fail(Assert.java:89) at
> org.apache.cxf.systest.jaxrs.JAXRSMultithreadedClientTest$WebClientWorker.run(JAXRSMultithreadedClientTest.java:208)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:857) at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.getResponse(HttpClientHTTPConduit.java:751)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.getResponseCode(HttpClientHTTPConduit.java:760)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1653)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1684)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1626)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1420)
> ... 19 more Caused by: java.lang.InterruptedException at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:386)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2096)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.getResponse(HttpClientHTTPConduit.java:731)
> ... 24 more Exception in thread "pool-12-thread-4" java.lang.AssertionError:
> WebClientWorker thread failed for 8,value8 at
> org.junit.Assert.fail(Assert.java:89) at
> org.apache.cxf.systest.jaxrs.JAXRSMultithreadedClientTest$WebClientWorker.run(JAXRSMultithreadedClientTest.java:208)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:857) {code}
> When this suite is run on Hotspot based JVMs, the test cases pass.This is
> reproducible by changing directory to systests/jaxrs, then executing:
> `
> {{mvn clean install -Dtest=JAXRSMultithreadedClientTest}}
> {{`}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9017) Regression in proxy-based restful client
[
https://issues.apache.org/jira/browse/CXF-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847258#comment-17847258
]
Andriy Redko commented on CXF-9017:
---
[~iiliev2] is it the duplicate of
https://issues.apache.org/jira/browse/CXF-8992 (same cause)? thank you
> Regression in proxy-based restful client
>
>
> Key: CXF-9017
> URL: https://issues.apache.org/jira/browse/CXF-9017
> Project: CXF
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Critical
>
> The memory leak fix introduced in
> https://issues.apache.org/jira/browse/CXF-8946 breaks the way the
> ClientProxyImpl works. It passes its ClientConfiguration down to sub-proxies.
> When those sub-proxies get garbage collected, that configuration gets closed.
> One of the objects that are closed is AbstractConduitSelector -> conduits.
> After that, any newly created sub-proxies will have misconfigured clients.
> For example, we are configuring TLSClientParameters on the conduit of the
> root, which gets wiped out and therefore the new child clients can no longer
> connect.
> {code:java}
> API api = JAXRSClientFactory.create(endpoint, , getCxfProviders(),
> true); // root proxy
> configure(api);//add TLSClientParameters
> SomeResource s = api.getSomeResource(); // sub-proxy
>
>
> SomeOtherResource s2 = api.get(); //broken{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9016) Upgrade Spring-Framework to 5.3.34 in Apache-cxf
[
https://issues.apache.org/jira/browse/CXF-9016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9016.
---
Resolution: Information Provided
It was done already
> Upgrade Spring-Framework to 5.3.34 in Apache-cxf
>
>
> Key: CXF-9016
> URL: https://issues.apache.org/jira/browse/CXF-9016
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.5.5, 3.5.6, 3.5.7, 3.5.8, 3.6.3
>Reporter: Nikhil
>Priority: Major
>
> We have a high severity security issue with spring-framework ::
> h2. Affected Spring Products and Versions
> Spring Framework
> * 6.1.0 - 6.1.5
> * 6.0.0 - 6.0.18
> * 5.3.0 - 5.3.33
> * Older, unsupported versions are also affected
>
> {*}Summary{*}: Applications that use UriComponentsBuilder in Spring Framework
> to parse an externally provided URL (e.g. through a query parameter) AND
> perform validation checks on the host of the parsed URL may be vulnerable to
> a open redirect [https://cwe.mitre.org/data/definitions/601.html] attack or
> to a SSRF attack if the URL is used after passing validation checks.
> This is the same as CVE-2024-22243
> [https://spring.io/security/cve-2024-22243] , but with different input.
>
> *Note:* This is the same as *CVE-2024-22259* and {*}CVE-2024-22243{*}, but
> with different input.
> –
> All these issues were fixed in Spring-Framework *5.3.34*
>
> *Could you please review and update Spring-Framework as needed in CXF package
> ?*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9013) Move performance benchmark to distribution samples folder
[ https://issues.apache.org/jira/browse/CXF-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9013: -- Fix Version/s: 4.1.0 > Move performance benchmark to distribution samples folder > - > > Key: CXF-9013 > URL: https://issues.apache.org/jira/browse/CXF-9013 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Priority: Minor > Fix For: 4.1.0 > > > Add JAX-RS suite to benchmarks. > CXF's benchmark performance suite currently includes JAX-WS based SOAP HTTP > Doc Lit. It would be nice to have a simple JAX-RS suite for rest verbs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9013) Move performance benchmark to distribution samples folder
[ https://issues.apache.org/jira/browse/CXF-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9013: -- Summary: Move performance benchmark to distribution samples folder (was: Add JAX-RS performance suite to benchmarks) > Move performance benchmark to distribution samples folder > - > > Key: CXF-9013 > URL: https://issues.apache.org/jira/browse/CXF-9013 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Priority: Minor > > Add JAX-RS suite to benchmarks. > CXF's benchmark performance suite currently includes JAX-WS based SOAP HTTP > Doc Lit. It would be nice to have a simple JAX-RS suite for rest verbs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9013) Move performance benchmark to distribution samples folder
[ https://issues.apache.org/jira/browse/CXF-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9013. --- Resolution: Fixed > Move performance benchmark to distribution samples folder > - > > Key: CXF-9013 > URL: https://issues.apache.org/jira/browse/CXF-9013 > Project: CXF > Issue Type: Improvement >Reporter: Jamie Mark Goodyear >Priority: Minor > Fix For: 4.1.0 > > > Add JAX-RS suite to benchmarks. > CXF's benchmark performance suite currently includes JAX-WS based SOAP HTTP > Doc Lit. It would be nice to have a simple JAX-RS suite for rest verbs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9015) Typo in JsonMapObjectReaderWriter treats \h as a special character instead of \n
[ https://issues.apache.org/jira/browse/CXF-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9015: -- Affects Version/s: 3.6.3 3.5.8 > Typo in JsonMapObjectReaderWriter treats \h as a special character instead of > \n > > > Key: CXF-9015 > URL: https://issues.apache.org/jira/browse/CXF-9015 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.8, 3.6.3, 4.0.4 >Reporter: Craig Perkins >Priority: Minor > Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4 > > > The JsonMapObjectReaderWriter class maintains a list of > [ESCAPED_CHARS|https://github.com/apache/cxf/blob/main/rt/rs/extensions/json-basic/src/main/java/org/apache/cxf/jaxrs/json/basic/JsonMapObjectReaderWriter.java#L45-L56] > which includes special characters that need to be escaped like the newline > (`\n`) and tab (`\t`) characters. This list also includes `\h`, but I can't > find any links to official documentation about this character needing to be > escaped. > According to this [SO post|https://stackoverflow.com/a/27516892] which > details escaped characters in JSON, it does not include `\h` in this list. > Issue in OpenSearch where this issue is discussed: > [https://github.com/opensearch-project/security/issues/2531#issuecomment-2111309193] > > PR to address the issue with more details: > [https://github.com/apache/cxf/pull/1872] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9015) Typo in JsonMapObjectReaderWriter treats \h as a special character instead of \n
[ https://issues.apache.org/jira/browse/CXF-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9015: -- Affects Version/s: 4.0.4 > Typo in JsonMapObjectReaderWriter treats \h as a special character instead of > \n > > > Key: CXF-9015 > URL: https://issues.apache.org/jira/browse/CXF-9015 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.4 >Reporter: Craig Perkins >Priority: Minor > > The JsonMapObjectReaderWriter class maintains a list of > [ESCAPED_CHARS|https://github.com/apache/cxf/blob/main/rt/rs/extensions/json-basic/src/main/java/org/apache/cxf/jaxrs/json/basic/JsonMapObjectReaderWriter.java#L45-L56] > which includes special characters that need to be escaped like the newline > (`\n`) and tab (`\t`) characters. This list also includes `\h`, but I can't > find any links to official documentation about this character needing to be > escaped. > According to this [SO post|https://stackoverflow.com/a/27516892] which > details escaped characters in JSON, it does not include `\h` in this list. > Issue in OpenSearch where this issue is discussed: > [https://github.com/opensearch-project/security/issues/2531#issuecomment-2111309193] > > PR to address the issue with more details: > [https://github.com/apache/cxf/pull/1872] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9015) Typo in JsonMapObjectReaderWriter treats \h as a special character instead of \n
[ https://issues.apache.org/jira/browse/CXF-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9015: -- Fix Version/s: 3.5.9 4.1.0 4.0.5 3.6.4 > Typo in JsonMapObjectReaderWriter treats \h as a special character instead of > \n > > > Key: CXF-9015 > URL: https://issues.apache.org/jira/browse/CXF-9015 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.4 >Reporter: Craig Perkins >Priority: Minor > Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4 > > > The JsonMapObjectReaderWriter class maintains a list of > [ESCAPED_CHARS|https://github.com/apache/cxf/blob/main/rt/rs/extensions/json-basic/src/main/java/org/apache/cxf/jaxrs/json/basic/JsonMapObjectReaderWriter.java#L45-L56] > which includes special characters that need to be escaped like the newline > (`\n`) and tab (`\t`) characters. This list also includes `\h`, but I can't > find any links to official documentation about this character needing to be > escaped. > According to this [SO post|https://stackoverflow.com/a/27516892] which > details escaped characters in JSON, it does not include `\h` in this list. > Issue in OpenSearch where this issue is discussed: > [https://github.com/opensearch-project/security/issues/2531#issuecomment-2111309193] > > PR to address the issue with more details: > [https://github.com/apache/cxf/pull/1872] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8976) Update to OpenTelemetry v1.38.0
[
https://issues.apache.org/jira/browse/CXF-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8976:
--
Summary: Update to OpenTelemetry v1.38.0 (was: Update to OpenTelemetry
v1.37.0)
> Update to OpenTelemetry v1.38.0
> ---
>
> Key: CXF-8976
> URL: https://issues.apache.org/jira/browse/CXF-8976
> Project: CXF
> Issue Type: Improvement
> Components: Tracing
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0
>
>
> The OpenTelemetry v1.35.0 SDKs switched to Brave 6:
> {noformat}
> "io.zipkin.brave:brave-bom:6.0.0",
> "io.zipkin.reporter2:zipkin-reporter-bom:3.2.1", {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845759#comment-17845759
]
Andriy Redko commented on CXF-9009:
---
I was able to reproduce the issue, it is not related to handleMessage but
happens before that, thank you [~juliojgd]
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 4.0.4
>Reporter: Julio J. Gomez Diaz
>Priority: Major
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-9009:
-
Assignee: Andriy Redko
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 4.0.4
>Reporter: Julio J. Gomez Diaz
>Assignee: Andriy Redko
>Priority: Major
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845746#comment-17845746
]
Andriy Redko edited comment on CXF-9009 at 5/12/24 9:27 PM:
[~juliojgd] please refer to the FAQ section regarding JAX-WS client proxies
thread safety [1], thank you. Out of curiosity, what is the use case to have
async invocation (which is already happening in another thread) executed in the
context of the thread pool?
[1] [https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?]
was (Author: reta):
[~juliojgd] please refer to the FAQ section regarding JAX-WS client proxies
thread safety [1], thank you.
[1] https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 4.0.4
>Reporter: Julio J. Gomez Diaz
>Priority: Major
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9009) Async operations fail in concurrent calls
[
https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845746#comment-17845746
]
Andriy Redko commented on CXF-9009:
---
[~juliojgd] please refer to the FAQ section regarding JAX-WS client proxies
thread safety [1], thank you.
[1] https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?
> Async operations fail in concurrent calls
> -
>
> Key: CXF-9009
> URL: https://issues.apache.org/jira/browse/CXF-9009
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 4.0.4
>Reporter: Julio J. Gomez Diaz
>Priority: Major
> Attachments: spring-soap.zip
>
>
> An exception occurs when a SOAP client is used concurrently in async
> operations, the exception is as follows:
>
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
> ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4]
> at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na]
> at
> com.example.demo.rest.RestController.lambda$async$1(RestController.java:25)
> ~[classes/:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> ~[na:na]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> ~[na:na]
> at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]
> Caused by: io.netty.channel.StacklessClosedChannelException: null
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown
> Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code}
>
> I created an reproducer application (find attached "spring-soap.zip") that
> acts as client and server, and this publishes the following operations:
> * [http://localhost:8080/async] -> it uses a soap client to call
> concurrently using an async operation (this {*}fails with the exception
> previously described{*})
> * [http://localhost:8080/sync] -> it uses a soap client to call concurrently
> using an ordinary operation (ends without errors)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown
[
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8987:
--
Fix Version/s: 4.1.0
3.6.4
> Java 21 - HttpClientHTTPConduit thread locked during shutdown
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Assignee: Andriy Redko
>Priority: Blocker
> Fix For: 4.1.0, 4.0.5, 3.6.4
>
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
> *- locked <0x00061cd2ab80> (a
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
> *at
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
> *at
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
> *at
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
> *at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>
> java.net.HttpClient.close
>
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown
[
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8987.
---
Resolution: Fixed
> Java 21 - HttpClientHTTPConduit thread locked during shutdown
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Assignee: Andriy Redko
>Priority: Blocker
> Fix For: 4.1.0, 4.0.5, 3.6.4
>
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
> *- locked <0x00061cd2ab80> (a
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
> *at
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
> *at
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
> *at
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
> *at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>
> java.net.HttpClient.close
>
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9007) NullPointerException in XMLStreamDataWriter.writeNode
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9007:
--
Fix Version/s: 4.1.0
4.0.5
> NullPointerException in XMLStreamDataWriter.writeNode
> -
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Magnus Holm
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.5
>
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5.
> We've had this issue on 4.0.3 and 4.0.4. We might've had it on previous
> versions as well, but I don't have build history going back that far.
> JDK versions: Corretto 17 (17.0.8-amzn), Zulu 17 (17.0.10-zulu) ++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9007) NullPointerException in XMLStreamDataWriter.writeNode
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845165#comment-17845165
]
Andriy Redko commented on CXF-9007:
---
[~maghol] I have submitted a potential fix but I cannot reproduce the problem
myself, any chances you could share the test case(s) that are failing for you
sporadically? Thank you.
> NullPointerException in XMLStreamDataWriter.writeNode
> -
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Magnus Holm
>Assignee: Andriy Redko
>Priority: Major
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5.
> We've had this issue on 4.0.3 and 4.0.4. We might've had it on previous
> versions as well, but I don't have build history going back that far.
> JDK versions: Corretto 17 (17.0.8-amzn), Zulu 17 (17.0.10-zulu) ++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9007) NullPointerException in XMLStreamDataWriter.writeNode
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9007:
--
Summary: NullPointerException in XMLStreamDataWriter.writeNode (was:
NullPointerException in client response-handling)
> NullPointerException in XMLStreamDataWriter.writeNode
> -
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Magnus Holm
>Assignee: Andriy Redko
>Priority: Major
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5.
> We've had this issue on 4.0.3 and 4.0.4. We might've had it on previous
> versions as well, but I don't have build history going back that far.
> JDK versions: Corretto 17 (17.0.8-amzn), Zulu 17 (17.0.10-zulu) ++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-9007) NullPointerException in client response-handling
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-9007:
-
Assignee: Andriy Redko
> NullPointerException in client response-handling
>
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Magnus Holm
>Assignee: Andriy Redko
>Priority: Major
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5.
> We've had this issue on 4.0.3 and 4.0.4. We might've had it on previous
> versions as well, but I don't have build history going back that far.
> JDK versions: Corretto 17 (17.0.8-amzn), Zulu 17 (17.0.10-zulu) ++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9011) WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL constructor
[
https://issues.apache.org/jira/browse/CXF-9011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9011.
---
Resolution: Fixed
> WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL
> constructor
> --
>
> Key: CXF-9011
> URL: https://issues.apache.org/jira/browse/CXF-9011
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 4.0.4
>Reporter: Francisco Mateo
>Priority: Minor
> Fix For: 4.1.0, 4.0.5
>
>
> The URL constructors were deprecated in Java 20
> [https://bugs.openjdk.org/browse/JDK-8294241].
> The template uses the deprecated constructor:
> [https://github.com/apache/cxf/blob/cxf-4.0.4/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/template/service.vm#L123]
> This becomes an issue when applications compile with warnings enabled, for
> example {{-Xlint:all -Werror}}
> Seems we could just switch to using {{URI.create(...).toURL()}} in the
> template since that has been available since Java 1.4
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9006:
--
Fix Version/s: 4.0.5
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Fix For: 4.1.0, 4.0.5
>
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9010) Update benchmark soap http doc lit suite for CXF 4.1.x
[ https://issues.apache.org/jira/browse/CXF-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9010. --- Resolution: Fixed > Update benchmark soap http doc lit suite for CXF 4.1.x > --- > > Key: CXF-9010 > URL: https://issues.apache.org/jira/browse/CXF-9010 > Project: CXF > Issue Type: Test >Reporter: Jamie Mark Goodyear >Priority: Trivial > Fix For: 4.1.0 > > > Update benchmark soap http doc lit suite for CXF 4.1.x > Test class KeystorePasswordCallback should update to use > org.apache.wss4j.common.ext.WSPasswordCallback. > Avoid transitive load from HTTP repo for encache (not issue on main CXF > build, just benchmark module). > Update slf4j-jdk14 version to align with CXF 4.1.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9011) WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL constructor
[
https://issues.apache.org/jira/browse/CXF-9011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9011:
--
Fix Version/s: 4.1.0
4.0.5
3.6.4
> WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL
> constructor
> --
>
> Key: CXF-9011
> URL: https://issues.apache.org/jira/browse/CXF-9011
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 4.0.4
>Reporter: Francisco Mateo
>Priority: Minor
> Fix For: 4.1.0, 4.0.5, 3.6.4
>
>
> The URL constructors were deprecated in Java 20
> [https://bugs.openjdk.org/browse/JDK-8294241].
> The template uses the deprecated constructor:
> [https://github.com/apache/cxf/blob/cxf-4.0.4/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/template/service.vm#L123]
> This becomes an issue when applications compile with warnings enabled, for
> example {{-Xlint:all -Werror}}
> Seems we could just switch to using {{URI.create(...).toURL()}} in the
> template since that has been available since Java 1.4
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9011) WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL constructor
[
https://issues.apache.org/jira/browse/CXF-9011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9011:
--
Fix Version/s: (was: 3.6.4)
> WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL
> constructor
> --
>
> Key: CXF-9011
> URL: https://issues.apache.org/jira/browse/CXF-9011
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 4.0.4
>Reporter: Francisco Mateo
>Priority: Minor
> Fix For: 4.1.0, 4.0.5
>
>
> The URL constructors were deprecated in Java 20
> [https://bugs.openjdk.org/browse/JDK-8294241].
> The template uses the deprecated constructor:
> [https://github.com/apache/cxf/blob/cxf-4.0.4/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/template/service.vm#L123]
> This becomes an issue when applications compile with warnings enabled, for
> example {{-Xlint:all -Werror}}
> Seems we could just switch to using {{URI.create(...).toURL()}} in the
> template since that has been available since Java 1.4
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9010) Update benchmark soap http doc lit suite for CXF 4.1.x
[ https://issues.apache.org/jira/browse/CXF-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9010: -- Fix Version/s: 4.1.0 > Update benchmark soap http doc lit suite for CXF 4.1.x > --- > > Key: CXF-9010 > URL: https://issues.apache.org/jira/browse/CXF-9010 > Project: CXF > Issue Type: Test >Reporter: Jamie Mark Goodyear >Priority: Trivial > Fix For: 4.1.0 > > > Update benchmark soap http doc lit suite for CXF 4.1.x > Test class KeystorePasswordCallback should update to use > org.apache.wss4j.common.ext.WSPasswordCallback. > Avoid transitive load from HTTP repo for encache (not issue on main CXF > build, just benchmark module). > Update slf4j-jdk14 version to align with CXF 4.1.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown
[
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8987:
-
Assignee: Andriy Redko
> Java 21 - HttpClientHTTPConduit thread locked during shutdown
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Assignee: Andriy Redko
>Priority: Blocker
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
> *- locked <0x00061cd2ab80> (a
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
> *at
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
> *at
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
> *at
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
> *at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>
> java.net.HttpClient.close
>
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown
[
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8987:
--
Fix Version/s: 4.0.5
> Java 21 - HttpClientHTTPConduit thread locked during shutdown
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Assignee: Andriy Redko
>Priority: Blocker
> Fix For: 4.0.5
>
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
> *- locked <0x00061cd2ab80> (a
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
> *at
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
> *at
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
> *at
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
> *at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>
> java.net.HttpClient.close
>
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9007) NullPointerException in client response-handling
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9007:
--
Affects Version/s: 4.0.3
> NullPointerException in client response-handling
>
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Magnus Holm
>Priority: Major
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5.
> We've had this issue on 4.0.3 and 4.0.4. We might've had it on previous
> versions as well, but I don't have build history going back that far.
> JDK versions: Corretto 17 (17.0.8-amzn), Zulu 17 (17.0.10-zulu) ++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9007) NullPointerException in client response-handling
[
https://issues.apache.org/jira/browse/CXF-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843442#comment-17843442
]
Andriy Redko commented on CXF-9007:
---
Thank you [~maghol] , could you please clarify if the issue started to appear
when have migrated from previous 4.0.x release(s)? Or you just started straight
with 4.0.4. Also, could you please share what JDK you have been using? (version
+ vendor). Thank you.
> NullPointerException in client response-handling
>
>
> Key: CXF-9007
> URL: https://issues.apache.org/jira/browse/CXF-9007
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.4
>Reporter: Magnus Holm
>Priority: Major
> Attachments: dispatch-impl-npe.txt, interceptor-npe.txt,
> invoke-async-npe.txt, invoke-sync-npe.txt
>
>
> We're encountering sporadic weird {{NullPointerException}} in various of our
> tests using different client configurations with wsdls. It seems to only
> occur right after initialising the client, e.g. only on the first call. I
> suspect it's some kind of race-condition, but I've not been able to create a
> reproducer. I was hoping maybe someone from the project would have insight
> into why this could be happening by looking at the stacktraces.
> The error we're hitting appears to be here:
> {code}
> java.lang.NullPointerException: Cannot invoke
> "org.w3c.dom.Node.getOwnerDocument()" because "nd" is null
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.writeNode(XMLStreamDataWriter.java:160)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:101)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:67)
> ~[cxf-core-4.0.4.jar:4.0.4]
> at
> org.apache.cxf.databinding.source.XMLStreamDataWriter.write(XMLStreamDataWriter.java:55)
> ~[cxf-core-4.0.4.jar:4.0.4]
> {code}
> Update: we're using cxf-rt-transports-http-hc5
--
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 Minimum JDK requirement - JDK-17 Jakarta Interceptors 2.2* 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]) was: Support Jakarta EE 11 Minimum JDK requirement - JDK-17 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) > Support Jakarta EE 11 > - > > Key: CXF-8828 > URL: https://issues.apache.org/jira/browse/CXF-8828 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.2.0 > > > Support Jakarta EE 11 > Minimum JDK requirement - JDK-17 > Jakarta Interceptors 2.2* > > 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]) -- 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:
- Brave 6
- OpenTelemetry 1.36.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])
- 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.2
([https://github.com/spring-projects/spring-boot/releases/tag/v3.2.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.1.0])
- *[DONE]* Spring Security 6.2
([https://github.com/spring-projects/spring-security/releases/tag/6.1.0])
- *[DONE]* Micrometer 1.12
([https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0|https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0-M1])
- {*}[DONE]{*}Micrometer Tracing 1.2
([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:
- Microprofile OpenAPI 3.1
([https://github.com/eclipse/microprofile-open-api/releases/tag/3.1])
- Microprofile Config 3.1
([https://github.com/eclipse/microprofile-config/releases/tag/3.1])
- 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 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
[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:
- Brave 6
- 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])
- 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.2
([https://github.com/spring-projects/spring-boot/releases/tag/v3.2.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.1.0])
- *[DONE]* Spring Security 6.2
([https://github.com/spring-projects/spring-security/releases/tag/6.1.0])
- *[DONE]* Micrometer 1.12
([https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0|https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0-M1])
- {*}[DONE]{*}Micrometer Tracing 1.2
([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:
- Microprofile OpenAPI 3.1
([https://github.com/eclipse/microprofile-open-api/releases/tag/3.1])
- Microprofile Config 3.1
([https://github.com/eclipse/microprofile-config/releases/tag/3.1])
- 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 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
[jira] [Resolved] (CXF-8951) Concurrent WebClient usage causes massive thread overhead
[ https://issues.apache.org/jira/browse/CXF-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8951. --- Resolution: Fixed > Concurrent WebClient usage causes massive thread overhead > - > > Key: CXF-8951 > URL: https://issues.apache.org/jira/browse/CXF-8951 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.6.2, 4.0.3, 3.6.3, 4.0.4 >Reporter: Lars Ködderitzsch >Assignee: Andriy Redko >Priority: Blocker > Fix For: 4.0.5, 3.6.4 > > Attachments: cxf-connector-threads.zip > > > Concurrent usage of Webclients causes massively more threads to be created in > cxf-3.6.x/4.x than before. > Supposedly this results from introducing a new conduit implementation based > on the "new" java http client compared to HttpUrlConnection before. > It seems that a new http client is created per requesting thread - and each > http client in turn creates an own pool of selector/worker threads. > To demonstate I've attached a test project with several methods to test > different scenarios. > Each tests launches a simple JAX-RS Server, configures/uses WebClients in > different configuration and submits 1000 requests via up to 100 parrallel > requestor threads. > The number of live threads in the JVM instance if printed after each request. > Baseline is the number of threads used by the server instance + the 100 > requesting threads. > > singleClientInstanceWithNewConduit -> reuses a threadsafe client instance, > thread count rises to 700+ live threads > singleClientInstanceWithOldConduit -> reuses a threadsafe client instance, > stays at about 200 threads > clientPerRequestWithOldConduit -> creates a client instance per request > (no closing!), keeps below 200 threads > clientPerRequestWithNewConduit -> creates a client instance per request > (no closing!), creates a runaway thread leak (!) > clientPerRequestWithNewConduit is additionally interesting because current > documentation is not clear about whether client instances > are required to be resource managed or not. > It appears that closing clients was not required up until cxf-3.6.0 and > documentation actively encourages creating new "lightweight" client instances > on the fly (see Thread safety in > [https://cxf.apache.org/docs/jax-rs-client-api.html]). > However, cxf-3.6+ implementation (and comments in CXF-8885) seem to suggest > that clients are in fact *not lightweight* (anymore?) but need to be closed, > when no longer used. > But then in turn WebClient/Client does not even implement > Closeable/Autoclosable. So, it's all quite muddy - and there doesn't seem to > be a real consensus on the idiomatic usage of Webclients. > It would be very nice if you could bring some clarity on this as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8951) Concurrent WebClient usage causes massive thread overhead
[ https://issues.apache.org/jira/browse/CXF-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839173#comment-17839173 ] Andriy Redko commented on CXF-8951: --- Documentation updated: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=49941 > Concurrent WebClient usage causes massive thread overhead > - > > Key: CXF-8951 > URL: https://issues.apache.org/jira/browse/CXF-8951 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.6.2, 4.0.3, 3.6.3, 4.0.4 >Reporter: Lars Ködderitzsch >Assignee: Andriy Redko >Priority: Blocker > Fix For: 4.0.5, 3.6.4 > > Attachments: cxf-connector-threads.zip > > > Concurrent usage of Webclients causes massively more threads to be created in > cxf-3.6.x/4.x than before. > Supposedly this results from introducing a new conduit implementation based > on the "new" java http client compared to HttpUrlConnection before. > It seems that a new http client is created per requesting thread - and each > http client in turn creates an own pool of selector/worker threads. > To demonstate I've attached a test project with several methods to test > different scenarios. > Each tests launches a simple JAX-RS Server, configures/uses WebClients in > different configuration and submits 1000 requests via up to 100 parrallel > requestor threads. > The number of live threads in the JVM instance if printed after each request. > Baseline is the number of threads used by the server instance + the 100 > requesting threads. > > singleClientInstanceWithNewConduit -> reuses a threadsafe client instance, > thread count rises to 700+ live threads > singleClientInstanceWithOldConduit -> reuses a threadsafe client instance, > stays at about 200 threads > clientPerRequestWithOldConduit -> creates a client instance per request > (no closing!), keeps below 200 threads > clientPerRequestWithNewConduit -> creates a client instance per request > (no closing!), creates a runaway thread leak (!) > clientPerRequestWithNewConduit is additionally interesting because current > documentation is not clear about whether client instances > are required to be resource managed or not. > It appears that closing clients was not required up until cxf-3.6.0 and > documentation actively encourages creating new "lightweight" client instances > on the fly (see Thread safety in > [https://cxf.apache.org/docs/jax-rs-client-api.html]). > However, cxf-3.6+ implementation (and comments in CXF-8885) seem to suggest > that clients are in fact *not lightweight* (anymore?) but need to be closed, > when no longer used. > But then in turn WebClient/Client does not even implement > Closeable/Autoclosable. So, it's all quite muddy - and there doesn't seem to > be a real consensus on the idiomatic usage of Webclients. > It would be very nice if you could bring some clarity on this as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8951) Concurrent WebClient usage causes massive thread overhead
[ https://issues.apache.org/jira/browse/CXF-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8951: -- Fix Version/s: 4.1.0 > Concurrent WebClient usage causes massive thread overhead > - > > Key: CXF-8951 > URL: https://issues.apache.org/jira/browse/CXF-8951 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.6.2, 4.0.3, 3.6.3, 4.0.4 >Reporter: Lars Ködderitzsch >Assignee: Andriy Redko >Priority: Blocker > Fix For: 4.1.0, 4.0.5, 3.6.4 > > Attachments: cxf-connector-threads.zip > > > Concurrent usage of Webclients causes massively more threads to be created in > cxf-3.6.x/4.x than before. > Supposedly this results from introducing a new conduit implementation based > on the "new" java http client compared to HttpUrlConnection before. > It seems that a new http client is created per requesting thread - and each > http client in turn creates an own pool of selector/worker threads. > To demonstate I've attached a test project with several methods to test > different scenarios. > Each tests launches a simple JAX-RS Server, configures/uses WebClients in > different configuration and submits 1000 requests via up to 100 parrallel > requestor threads. > The number of live threads in the JVM instance if printed after each request. > Baseline is the number of threads used by the server instance + the 100 > requesting threads. > > singleClientInstanceWithNewConduit -> reuses a threadsafe client instance, > thread count rises to 700+ live threads > singleClientInstanceWithOldConduit -> reuses a threadsafe client instance, > stays at about 200 threads > clientPerRequestWithOldConduit -> creates a client instance per request > (no closing!), keeps below 200 threads > clientPerRequestWithNewConduit -> creates a client instance per request > (no closing!), creates a runaway thread leak (!) > clientPerRequestWithNewConduit is additionally interesting because current > documentation is not clear about whether client instances > are required to be resource managed or not. > It appears that closing clients was not required up until cxf-3.6.0 and > documentation actively encourages creating new "lightweight" client instances > on the fly (see Thread safety in > [https://cxf.apache.org/docs/jax-rs-client-api.html]). > However, cxf-3.6+ implementation (and comments in CXF-8885) seem to suggest > that clients are in fact *not lightweight* (anymore?) but need to be closed, > when no longer used. > But then in turn WebClient/Client does not even implement > Closeable/Autoclosable. So, it's all quite muddy - and there doesn't seem to > be a real consensus on the idiomatic usage of Webclients. > It would be very nice if you could bring some clarity on this as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8530) Error in OpenAPI descriptor for byte array properties
[
https://issues.apache.org/jira/browse/CXF-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838978#comment-17838978
]
Andriy Redko commented on CXF-8530:
---
Finally, the fix was merged!
https://github.com/swagger-api/swagger-core/pull/3955
> Error in OpenAPI descriptor for byte array properties
> -
>
> Key: CXF-8530
> URL: https://issues.apache.org/jira/browse/CXF-8530
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.4.3
>Reporter: Luca Leonardo Scorcia
>Priority: Major
> Attachments: repro.patch
>
>
> When using OpenAPIFeature to generate the OpenAPIv3 description document for
> a CXF web service, the built-in type mapper generates a wrong output in the
> JSON document.
> For repro, take the example project at
> [https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_openapi_v3_web]
> and add a byte[] property to the Item class, like in the attached patch file.
> Run the project and scroll to the end of the generated json document at
> [http://localhost:9000/app/openapi.json]:
> {{"components" : {}}
> {{ "schemas" : {}}
> {{ "Item" : {}}
> {{ "type" : "object",}}
> {{ "properties" : {}}
> {{ "name" : {}}
> {{ "type" : "string"}}
> {{ },}}
> {{ "value" : {}}
> {{ "type" : "string"}}
> {{ },}}
> {{ {color:#ff}"binary" : {{color}}}
> {{{color:#ff} "type" : "array",{color}}}
> {{{color:#ff} "items" : {{color}}}
> {{{color:#ff} "type" : "string",{color}}}
> {{{color:#ff} "format" : "byte"{color}}}
> {{{color:#ff} }{color}}}
> {{{color:#ff} }{color}}}
> }
> }
> }
> }
> This is interpreted by OpenAPI codegen tools as a List of byte[].
> According to the OpenAPIv3 spec, byte arrays should actually be represented as
> {
> "type": "string",
> "format": "byte"
> }
> without the "type": "array" wrapper.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8995) OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
[
https://issues.apache.org/jira/browse/CXF-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838826#comment-17838826
]
Andriy Redko commented on CXF-8995:
---
[~devflo] OK, it seems the issue is that Camel 3.22.1 is using old ASM 8.x [1]
where Apache CXF uses at least {color:#00}9.5 [2]{color}
[1] [https://github.com/apache/camel/blob/camel-3.22.1/parent/pom.xml#L72]
[2] https://github.com/apache/cxf/blob/cxf-3.6.2/parent/pom.xml#L59
> OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds
> for length 7
> -
>
> Key: CXF-8995
> URL: https://issues.apache.org/jira/browse/CXF-8995
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3, 4.0.4
>Reporter: Florian Wermelskirchen
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.5, 3.6.4
>
>
> After upgrading our software to apache camel 3.22.1 and cxf 3.6.2 we get this
> Error running our Tests.
> {code:java}
> 2024-04-02 14:44:01,698 | ERROR | Test worker |
> org.apache.camel.impl.engine.AbstractCamelContext | Error starting
> CamelContext (camel-1) due to exception thrown: Index 7 out of bounds for
> length 7
> java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
> at org.apache.cxf.common.util.OpcodesProxy.(OpcodesProxy.java:37)
> at
> org.apache.cxf.common.util.ASMHelperImpl.getOpCodes(ASMHelperImpl.java:105)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:200)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> at
> org.apache.cxf.jaxws.spi.WrapperClassCreatorProxyService.generate(WrapperClassCreatorProxyService.java:40)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.createServer(CxfConsumer.java:75)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.doStart(CxfConsumer.java:107)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.startService(AbstractCamelContext.java:3760)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRouteConsumers(InternalRouteStartupManager.java:401)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartRouteConsumers(InternalRouteStartupManager.java:319)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.safelyStartRouteServices(InternalRouteStartupManager.java:213)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRoutes(InternalRouteStartupManager.java:147)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:3445)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:3114)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:3069)
> at
> org.apache.camel.spring.boot.SpringBootCamelContext.doStart(SpringBootCamelContext.java:43)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2718)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:262)
> at
> org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:119)
> at
>
[jira] [Updated] (CXF-8976) Update to OpenTelemetry v1.37.0
[
https://issues.apache.org/jira/browse/CXF-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8976:
--
Summary: Update to OpenTelemetry v1.37.0 (was: Update to OpenTelemetry
v1.36.0)
> Update to OpenTelemetry v1.37.0
> ---
>
> Key: CXF-8976
> URL: https://issues.apache.org/jira/browse/CXF-8976
> Project: CXF
> Issue Type: Improvement
> Components: Tracing
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0
>
>
> The OpenTelemetry v1.35.0 SDKs switched to Brave 6:
> {noformat}
> "io.zipkin.brave:brave-bom:6.0.0",
> "io.zipkin.reporter2:zipkin-reporter-bom:3.2.1", {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8891) Evaluate changes to org.glassfish.jaxb:jaxb-runtime:4.0.3
[
https://issues.apache.org/jira/browse/CXF-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8891.
---
Resolution: Won't Fix
> Evaluate changes to org.glassfish.jaxb:jaxb-runtime:4.0.3
> -
>
> Key: CXF-8891
> URL: https://issues.apache.org/jira/browse/CXF-8891
> Project: CXF
> Issue Type: Task
> Components: Core
>Affects Versions: 4.0.2
>Reporter: Lars Uffmann
>Priority: Major
> Fix For: 4.1.0
>
>
> In the latest release of {*}jaxb-runtime{*}, 4.0.3, a change has been made
> which might affect CXF by introducing incompatibilities and/or
> interoperability issues.
> The changes are related to the JAXB Context Property
> *org.glassfish.jaxb.defaultNamespaceRemap*
> [https://github.com/eclipse-ee4j/jaxb-ri/issues/1715]
> For example, until 4.0.3, an XmlRootElement is marshaled as
> {code:java}
> xmlns:ns2="http://demo.ws.example.com;>Klaus{code}
> With 4.0.3 it will become
> {code:java}
> xmlns="http://demo.ws.example.com;>Klaus{code}
> In your parent pom, the version for jaxb-runtime is still 3.0.2. However,
> recent Spring boot versions >= 3.0.x are managing the 4.0.x version of
> jaxb-runtime. I stumbled over this issue after upgrading to the latest Spring
> Boot (3.0.8 / 3.1.1) release, which will upgrade the jaxb-runtime from 4.0.2
> to 4.0.3.
> I created an Issue in jaxb-ri as well:
> [https://github.com/eclipse-ee4j/jaxb-ri/issues/1724]
> Im not sure how this might affect cxf users. The web service affected by this
> issue is as simple as it can get and is used exclusively for integration
> testing purposes. A client using cxf could no longer talk to a server using
> spring web services.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8891) Evaluate changes to org.glassfish.jaxb:jaxb-runtime:4.0.3
[
https://issues.apache.org/jira/browse/CXF-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836590#comment-17836590
]
Andriy Redko commented on CXF-8891:
---
Thanks [~cachescrubber] , closing this one since we already updated to 4.0.4 in
the branch.
> Evaluate changes to org.glassfish.jaxb:jaxb-runtime:4.0.3
> -
>
> Key: CXF-8891
> URL: https://issues.apache.org/jira/browse/CXF-8891
> Project: CXF
> Issue Type: Task
> Components: Core
>Affects Versions: 4.0.2
>Reporter: Lars Uffmann
>Priority: Major
> Fix For: 4.1.0
>
>
> In the latest release of {*}jaxb-runtime{*}, 4.0.3, a change has been made
> which might affect CXF by introducing incompatibilities and/or
> interoperability issues.
> The changes are related to the JAXB Context Property
> *org.glassfish.jaxb.defaultNamespaceRemap*
> [https://github.com/eclipse-ee4j/jaxb-ri/issues/1715]
> For example, until 4.0.3, an XmlRootElement is marshaled as
> {code:java}
> xmlns:ns2="http://demo.ws.example.com;>Klaus{code}
> With 4.0.3 it will become
> {code:java}
> xmlns="http://demo.ws.example.com;>Klaus{code}
> In your parent pom, the version for jaxb-runtime is still 3.0.2. However,
> recent Spring boot versions >= 3.0.x are managing the 4.0.x version of
> jaxb-runtime. I stumbled over this issue after upgrading to the latest Spring
> Boot (3.0.8 / 3.1.1) release, which will upgrade the jaxb-runtime from 4.0.2
> to 4.0.3.
> I created an Issue in jaxb-ri as well:
> [https://github.com/eclipse-ee4j/jaxb-ri/issues/1724]
> Im not sure how this might affect cxf users. The web service affected by this
> issue is as simple as it can get and is used exclusively for integration
> testing purposes. A client using cxf could no longer talk to a server using
> spring web services.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9002) JAXRSMultithreadedClientTest test cases failing on IBM JDK.
[
https://issues.apache.org/jira/browse/CXF-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836585#comment-17836585
]
Andriy Redko commented on CXF-9002:
---
Thank you folks, I have created a ticket [1] for INFRA team to add OpenJ9
21.0.2 (IBM Semeru) to Jenkins so we could make it part of the CI.
[1] https://issues.apache.org/jira/browse/INFRA-25706
> JAXRSMultithreadedClientTest test cases failing on IBM JDK.
> ---
>
> Key: CXF-9002
> URL: https://issues.apache.org/jira/browse/CXF-9002
> Project: CXF
> Issue Type: Test
> Components: JAX-RS
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
>
> JAXRSMultithreadedClientTest test cases failing on IBM JDK (Semeru 17).
> There is a JAXRS system test failure for {{JAXRSMultithreadedClientTest}}
> test cases:
> JAXRSMultithreadedClientTest.testStatefulWebClientThreadLocalWithCopy
> JAXRSMultithreadedClientTest.testStatefulWebClientWithCopy
> JAXRSMultithreadedClientTest.testThreadSafeProxyWithCopy
> The commonality between these tests are {{threadSafe }}is set to false, which
> triggers a copy of existing client with WebClient.fromClient.
> The error traces contains the following shape:
> {{`}}
> {{Exception in thread "pool-12-thread-2" java.lang.AssertionError:
> WebClientWorker thread failed for 10,value10 at
> org.junit.Assert.fail(Assert.java:89) at
> org.apache.cxf.systest.jaxrs.JAXRSMultithreadedClientTest$WebClientWorker.run(JAXRSMultithreadedClientTest.java:208)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:857) at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.getResponse(HttpClientHTTPConduit.java:751)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.getResponseCode(HttpClientHTTPConduit.java:760)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1653)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1684)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1626)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1420)
> ... 19 more Caused by: java.lang.InterruptedException at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:386)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2096)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.getResponse(HttpClientHTTPConduit.java:731)
> ... 24 more Exception in thread "pool-12-thread-4" java.lang.AssertionError:
> WebClientWorker thread failed for 8,value8 at
> org.junit.Assert.fail(Assert.java:89) at
> org.apache.cxf.systest.jaxrs.JAXRSMultithreadedClientTest$WebClientWorker.run(JAXRSMultithreadedClientTest.java:208)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:857)}}
> {{`}}
> When this suite is run on Hotspot based JVMs, the test cases pass.This is
> reproducible by changing directory to systests/jaxrs, then executing:
> `
> {{mvn clean install -Dtest=JAXRSMultithreadedClientTest}}
> {{`}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8671) Support Jakarta EE 10
[
https://issues.apache.org/jira/browse/CXF-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836141#comment-17836141
]
Andriy Redko commented on CXF-8671:
---
Restarted the discussion here [1], so we could have snapshots available. Thanks
[~rzo1] !
[1] https://lists.apache.org/thread/vcc1jrwwk65c1mljxncdovwc1vxp5zj5
> Support Jakarta EE 10
> -
>
> Key: CXF-8671
> URL: https://issues.apache.org/jira/browse/CXF-8671
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0
>
>
> 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:
> - Brave 6
> - OpenTelemetry 1.36.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])
> - 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.2
> ([https://github.com/spring-projects/spring-boot/releases/tag/v3.2.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.1.0])
> - *[DONE]* Spring Security 6.2
> ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0])
> - *[DONE]* Micrometer 1.12
> ([https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0|https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0-M1])
> - {*}[DONE]{*}Micrometer Tracing 1.2
> ([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:
> - Microprofile OpenAPI 3.1
> ([https://github.com/eclipse/microprofile-open-api/releases/tag/3.1])
> - Microprofile Config 3.1
> ([https://github.com/eclipse/microprofile-config/releases/tag/3.1])
> - 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]
>
> Integration branch:
> - [https://github.com/apache/cxf/tree/CXF-8671]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8971.
---
Resolution: Fixed
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 4.0.4
>Reporter: Freeman Yue Fang
>Priority: Major
> Fix For: 4.0.5
>
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8971:
--
Affects Version/s: 4.0.4
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 4.0.4
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8971:
--
Fix Version/s: 4.0.5
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 4.0.4
>Reporter: Freeman Yue Fang
>Priority: Major
> Fix For: 4.0.5
>
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9001) CDI extension not comptible with IBM Semeru
[ https://issues.apache.org/jira/browse/CXF-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9001. --- Resolution: Fixed > CDI extension not comptible with IBM Semeru > --- > > Key: CXF-9001 > URL: https://issues.apache.org/jira/browse/CXF-9001 > Project: CXF > Issue Type: Task >Affects Versions: 3.6.3, 4.0.4 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 4.0.5, 3.6.4 > > > Long story short CXF tries to handle "singleton" by using a set on bean > instances which means hashCode will be triggered but Semeru not having a > native hashcode it is delegated to the instance for normal scoped proxies and > at startup the instance does not always exists - context is not always up > like for request scoped. > Technically this is also an error since deduplication should have happen on > the bean to respect the application and not the instance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9001) CDI extension not comptible with IBM Semeru
[ https://issues.apache.org/jira/browse/CXF-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9001: -- Affects Version/s: 4.0.4 3.6.3 > CDI extension not comptible with IBM Semeru > --- > > Key: CXF-9001 > URL: https://issues.apache.org/jira/browse/CXF-9001 > Project: CXF > Issue Type: Task >Affects Versions: 3.6.3, 4.0.4 >Reporter: Romain Manni-Bucau >Priority: Major > > Long story short CXF tries to handle "singleton" by using a set on bean > instances which means hashCode will be triggered but Semeru not having a > native hashcode it is delegated to the instance for normal scoped proxies and > at startup the instance does not always exists - context is not always up > like for request scoped. > Technically this is also an error since deduplication should have happen on > the bean to respect the application and not the instance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9001) CDI extension not comptible with IBM Semeru
[ https://issues.apache.org/jira/browse/CXF-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9001: -- Fix Version/s: 4.0.5 3.6.4 > CDI extension not comptible with IBM Semeru > --- > > Key: CXF-9001 > URL: https://issues.apache.org/jira/browse/CXF-9001 > Project: CXF > Issue Type: Task >Affects Versions: 3.6.3, 4.0.4 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 4.0.5, 3.6.4 > > > Long story short CXF tries to handle "singleton" by using a set on bean > instances which means hashCode will be triggered but Semeru not having a > native hashcode it is delegated to the instance for normal scoped proxies and > at startup the instance does not always exists - context is not always up > like for request scoped. > Technically this is also an error since deduplication should have happen on > the bean to respect the application and not the instance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9001) CDI extension not comptible with IBM Semeru
[ https://issues.apache.org/jira/browse/CXF-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9001: -- Description: Long story short CXF tries to handle "singleton" by using a set on bean instances which means hashCode will be triggered but Semeru not having a native hashcode it is delegated to the instance for normal scoped proxies and at startup the instance does not always exists - context is not always up like for request scoped. Technically this is also an error since deduplication should have happen on the bean to respect the application and not the instance. was: Long story short CXF tries to handle "singleton" by using a set on bean instances which means hashCode will be triggered but semuru not having a native hashcode it is delegated to the instance for normal scoped proxies and at startup the instance does not always exists - context is not always up like for request scoped. Technically this is also an error since deduplication should have happent on the bean to respect the application and not the instance. > CDI extension not comptible with IBM Semeru > --- > > Key: CXF-9001 > URL: https://issues.apache.org/jira/browse/CXF-9001 > Project: CXF > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > Long story short CXF tries to handle "singleton" by using a set on bean > instances which means hashCode will be triggered but Semeru not having a > native hashcode it is delegated to the instance for normal scoped proxies and > at startup the instance does not always exists - context is not always up > like for request scoped. > Technically this is also an error since deduplication should have happen on > the bean to respect the application and not the instance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9001) CDI extension not comptible with IBM Semeru
[ https://issues.apache.org/jira/browse/CXF-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9001: -- Summary: CDI extension not comptible with IBM Semeru (was: CDI extension not comptible with IBM Semuru) > CDI extension not comptible with IBM Semeru > --- > > Key: CXF-9001 > URL: https://issues.apache.org/jira/browse/CXF-9001 > Project: CXF > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > Long story short CXF tries to handle "singleton" by using a set on bean > instances which means hashCode will be triggered but semuru not having a > native hashcode it is delegated to the instance for normal scoped proxies and > at startup the instance does not always exists - context is not always up > like for request scoped. > Technically this is also an error since deduplication should have happent on > the bean to respect the application and not the instance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9000) Uri resolve timeout hardcodet
[ https://issues.apache.org/jira/browse/CXF-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9000. --- Resolution: Duplicate > Uri resolve timeout hardcodet > - > > Key: CXF-9000 > URL: https://issues.apache.org/jira/browse/CXF-9000 > Project: CXF > Issue Type: Bug > Components: Core, Soap Binding >Affects Versions: 4.0.4 >Reporter: Dirk B. >Priority: Critical > Labels: CXF, URIResolver, timeouts > > JaxWsDynamicClientFactory.createClient() > - WSDL-Url nicht erreichbar --> z.B. Service down > - irgendwann wird "org.apache.cxf.resource.URIResolver.createInputStream() > aufgerufen mit folgenden Fehlern: > -- harcodierte Timeouts stoppen die Applikation > -- Suche nach eine WebUrl im FileSystem -> Sichrheitslücke > > Die gesamte Klasse weisst viele Warnungen auf. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8628) Unable to set the timeout for JaxWsDynamicClientFactory download WSDL document
[
https://issues.apache.org/jira/browse/CXF-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834708#comment-17834708
]
Andriy Redko commented on CXF-8628:
---
The solution is to configure following JVM system properties:
-Dsun.net.client.defaultReadTimeout=6
-Dsun.net.client.defaultConnectTimeout=3
> Unable to set the timeout for JaxWsDynamicClientFactory download WSDL document
> --
>
> Key: CXF-8628
> URL: https://issues.apache.org/jira/browse/CXF-8628
> Project: CXF
> Issue Type: Bug
> Environment: cxf-rt-frontend-simple-3.3.0.jar
>Reporter: winston chen
>Priority: Major
>
> {code:java}
> JaxWsDynamicClientFactory jaxWsDynamicClientFactory =
> JaxWsDynamicClientFactory.newInstance();
> Client client = jaxWsDynamicClientFactory.createClient(url);
> {code}
>
> When CXF creates clients through urls, there is no interface that allows us
> to set a timeout for downloading WSDL. If the WSDL file download is not
> completed for a long time, the current thread will always be running. It may
> cause the system to become unusable.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8996) JAXRS Bean introspection utility Beanspector relies on Class.getMethods natural order
[
https://issues.apache.org/jira/browse/CXF-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8996.
---
Resolution: Fixed
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order
> -
>
> Key: CXF-8996
> URL: https://issues.apache.org/jira/browse/CXF-8996
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 3.5.9, 4.0.5, 3.6.4
>
>
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order.
> For most JVMs the Beanspector Tests will pass, however IBM Java does not
> return methods in the same ordering. Note: Class.getMethods does not provide
> a prescribed ordering of methods.
> When CXF 4.0.x main branch is built, we'll observe:
> {{Apache CXF JAX-RS Extensions: Search fails.}}
> {{{}[ERROR] Failures:{}}}{{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans{}}}{{{}[ERROR]
> Run 1: BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 2:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 3:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 4:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}
> {{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans
> - Time elapsed: 0.001 s <<< FAILURE!{}}}{{{}java.lang.AssertionError:
> Expected exception: java.lang.IllegalArgumentException{}}}
> We can improve this behaviour by detecting when IBM Java is in use, and
> having IBM process declared methods first, then process remaining methods.
> This will make IBM behave more like other JVMs.
> I will provide a PR with the change in place. Currently testing on a variety
> of platforms/JVMs to ensure tests pass.
> {{//Class.getMethods does not provide an ordering.}}
> {{//IBM Java tends to have a different ordering than other JVMs, so process
> declared methods first.}}
> {{//Process remaining methods after to not miss getter/setters.}}
> {{if ("IBM Corporation".equals(System.getProperty("java.vendor"))) {}}
> {{processMethods(tclass.getDeclaredMethods());}}
> {{}}}
> {{processMethods(tclass.getMethods());}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8996) JAXRS Bean introspection utility Beanspector relies on Class.getMethods natural order
[
https://issues.apache.org/jira/browse/CXF-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8996:
--
Affects Version/s: 3.6.3
3.5.8
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order
> -
>
> Key: CXF-8996
> URL: https://issues.apache.org/jira/browse/CXF-8996
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.0.5
>
>
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order.
> For most JVMs the Beanspector Tests will pass, however IBM Java does not
> return methods in the same ordering. Note: Class.getMethods does not provide
> a prescribed ordering of methods.
> When CXF 4.0.x main branch is built, we'll observe:
> {{Apache CXF JAX-RS Extensions: Search fails.}}
> {{{}[ERROR] Failures:{}}}{{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans{}}}{{{}[ERROR]
> Run 1: BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 2:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 3:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 4:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}
> {{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans
> - Time elapsed: 0.001 s <<< FAILURE!{}}}{{{}java.lang.AssertionError:
> Expected exception: java.lang.IllegalArgumentException{}}}
> We can improve this behaviour by detecting when IBM Java is in use, and
> having IBM process declared methods first, then process remaining methods.
> This will make IBM behave more like other JVMs.
> I will provide a PR with the change in place. Currently testing on a variety
> of platforms/JVMs to ensure tests pass.
> {{//Class.getMethods does not provide an ordering.}}
> {{//IBM Java tends to have a different ordering than other JVMs, so process
> declared methods first.}}
> {{//Process remaining methods after to not miss getter/setters.}}
> {{if ("IBM Corporation".equals(System.getProperty("java.vendor"))) {}}
> {{processMethods(tclass.getDeclaredMethods());}}
> {{}}}
> {{processMethods(tclass.getMethods());}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8996) JAXRS Bean introspection utility Beanspector relies on Class.getMethods natural order
[
https://issues.apache.org/jira/browse/CXF-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8996:
--
Fix Version/s: 3.5.9
3.6.4
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order
> -
>
> Key: CXF-8996
> URL: https://issues.apache.org/jira/browse/CXF-8996
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 3.5.9, 4.0.5, 3.6.4
>
>
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order.
> For most JVMs the Beanspector Tests will pass, however IBM Java does not
> return methods in the same ordering. Note: Class.getMethods does not provide
> a prescribed ordering of methods.
> When CXF 4.0.x main branch is built, we'll observe:
> {{Apache CXF JAX-RS Extensions: Search fails.}}
> {{{}[ERROR] Failures:{}}}{{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans{}}}{{{}[ERROR]
> Run 1: BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 2:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 3:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 4:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}
> {{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans
> - Time elapsed: 0.001 s <<< FAILURE!{}}}{{{}java.lang.AssertionError:
> Expected exception: java.lang.IllegalArgumentException{}}}
> We can improve this behaviour by detecting when IBM Java is in use, and
> having IBM process declared methods first, then process remaining methods.
> This will make IBM behave more like other JVMs.
> I will provide a PR with the change in place. Currently testing on a variety
> of platforms/JVMs to ensure tests pass.
> {{//Class.getMethods does not provide an ordering.}}
> {{//IBM Java tends to have a different ordering than other JVMs, so process
> declared methods first.}}
> {{//Process remaining methods after to not miss getter/setters.}}
> {{if ("IBM Corporation".equals(System.getProperty("java.vendor"))) {}}
> {{processMethods(tclass.getDeclaredMethods());}}
> {{}}}
> {{processMethods(tclass.getMethods());}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8995) OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
[
https://issues.apache.org/jira/browse/CXF-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834275#comment-17834275
]
Andriy Redko commented on CXF-8995:
---
I think I know where is it coming from ... will take it
> OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds
> for length 7
> -
>
> Key: CXF-8995
> URL: https://issues.apache.org/jira/browse/CXF-8995
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3
>Reporter: Florian Wermelskirchen
>Assignee: Andriy Redko
>Priority: Major
>
> After upgrading our software to apache camel 3.22.1 and cxf 3.6.2 we get this
> Error running our Tests.
> {code:java}
> 2024-04-02 14:44:01,698 | ERROR | Test worker |
> org.apache.camel.impl.engine.AbstractCamelContext | Error starting
> CamelContext (camel-1) due to exception thrown: Index 7 out of bounds for
> length 7
> java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
> at org.apache.cxf.common.util.OpcodesProxy.(OpcodesProxy.java:37)
> at
> org.apache.cxf.common.util.ASMHelperImpl.getOpCodes(ASMHelperImpl.java:105)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:200)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> at
> org.apache.cxf.jaxws.spi.WrapperClassCreatorProxyService.generate(WrapperClassCreatorProxyService.java:40)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.createServer(CxfConsumer.java:75)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.doStart(CxfConsumer.java:107)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.startService(AbstractCamelContext.java:3760)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRouteConsumers(InternalRouteStartupManager.java:401)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartRouteConsumers(InternalRouteStartupManager.java:319)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.safelyStartRouteServices(InternalRouteStartupManager.java:213)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRoutes(InternalRouteStartupManager.java:147)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:3445)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:3114)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:3069)
> at
> org.apache.camel.spring.boot.SpringBootCamelContext.doStart(SpringBootCamelContext.java:43)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2718)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:262)
> at
> org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:119)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler$8.execute(CamelAnnotationsHandler.java:407)
> at
> org.apache.camel.test.spring.junit5.CamelSpringTestHelper.doToSpringCamelContexts(CamelSpringTestHelper.java:108)
> at
>
[jira] [Updated] (CXF-8995) OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
[
https://issues.apache.org/jira/browse/CXF-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8995:
--
Fix Version/s: 4.0.5
3.6.4
> OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds
> for length 7
> -
>
> Key: CXF-8995
> URL: https://issues.apache.org/jira/browse/CXF-8995
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3, 4.0.4
>Reporter: Florian Wermelskirchen
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.5, 3.6.4
>
>
> After upgrading our software to apache camel 3.22.1 and cxf 3.6.2 we get this
> Error running our Tests.
> {code:java}
> 2024-04-02 14:44:01,698 | ERROR | Test worker |
> org.apache.camel.impl.engine.AbstractCamelContext | Error starting
> CamelContext (camel-1) due to exception thrown: Index 7 out of bounds for
> length 7
> java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
> at org.apache.cxf.common.util.OpcodesProxy.(OpcodesProxy.java:37)
> at
> org.apache.cxf.common.util.ASMHelperImpl.getOpCodes(ASMHelperImpl.java:105)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:200)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> at
> org.apache.cxf.jaxws.spi.WrapperClassCreatorProxyService.generate(WrapperClassCreatorProxyService.java:40)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.createServer(CxfConsumer.java:75)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.doStart(CxfConsumer.java:107)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.startService(AbstractCamelContext.java:3760)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRouteConsumers(InternalRouteStartupManager.java:401)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartRouteConsumers(InternalRouteStartupManager.java:319)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.safelyStartRouteServices(InternalRouteStartupManager.java:213)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRoutes(InternalRouteStartupManager.java:147)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:3445)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:3114)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:3069)
> at
> org.apache.camel.spring.boot.SpringBootCamelContext.doStart(SpringBootCamelContext.java:43)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2718)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:262)
> at
> org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:119)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler$8.execute(CamelAnnotationsHandler.java:407)
> at
> org.apache.camel.test.spring.junit5.CamelSpringTestHelper.doToSpringCamelContexts(CamelSpringTestHelper.java:108)
> at
>
[jira] [Updated] (CXF-8995) OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
[
https://issues.apache.org/jira/browse/CXF-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8995:
--
Affects Version/s: 4.0.4
> OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds
> for length 7
> -
>
> Key: CXF-8995
> URL: https://issues.apache.org/jira/browse/CXF-8995
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3, 4.0.4
>Reporter: Florian Wermelskirchen
>Assignee: Andriy Redko
>Priority: Major
>
> After upgrading our software to apache camel 3.22.1 and cxf 3.6.2 we get this
> Error running our Tests.
> {code:java}
> 2024-04-02 14:44:01,698 | ERROR | Test worker |
> org.apache.camel.impl.engine.AbstractCamelContext | Error starting
> CamelContext (camel-1) due to exception thrown: Index 7 out of bounds for
> length 7
> java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
> at org.apache.cxf.common.util.OpcodesProxy.(OpcodesProxy.java:37)
> at
> org.apache.cxf.common.util.ASMHelperImpl.getOpCodes(ASMHelperImpl.java:105)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:200)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> at
> org.apache.cxf.jaxws.spi.WrapperClassCreatorProxyService.generate(WrapperClassCreatorProxyService.java:40)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.createServer(CxfConsumer.java:75)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.doStart(CxfConsumer.java:107)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.startService(AbstractCamelContext.java:3760)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRouteConsumers(InternalRouteStartupManager.java:401)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartRouteConsumers(InternalRouteStartupManager.java:319)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.safelyStartRouteServices(InternalRouteStartupManager.java:213)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRoutes(InternalRouteStartupManager.java:147)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:3445)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:3114)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:3069)
> at
> org.apache.camel.spring.boot.SpringBootCamelContext.doStart(SpringBootCamelContext.java:43)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2718)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:262)
> at
> org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:119)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler$8.execute(CamelAnnotationsHandler.java:407)
> at
> org.apache.camel.test.spring.junit5.CamelSpringTestHelper.doToSpringCamelContexts(CamelSpringTestHelper.java:108)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler.handleCamelContextStartup(CamelAnnotationsHandler.java:400)
> at
>
[jira] [Assigned] (CXF-8995) OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
[
https://issues.apache.org/jira/browse/CXF-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8995:
-
Assignee: Andriy Redko
> OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds
> for length 7
> -
>
> Key: CXF-8995
> URL: https://issues.apache.org/jira/browse/CXF-8995
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3
>Reporter: Florian Wermelskirchen
>Assignee: Andriy Redko
>Priority: Major
>
> After upgrading our software to apache camel 3.22.1 and cxf 3.6.2 we get this
> Error running our Tests.
> {code:java}
> 2024-04-02 14:44:01,698 | ERROR | Test worker |
> org.apache.camel.impl.engine.AbstractCamelContext | Error starting
> CamelContext (camel-1) due to exception thrown: Index 7 out of bounds for
> length 7
> java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
> at org.apache.cxf.common.util.OpcodesProxy.(OpcodesProxy.java:37)
> at
> org.apache.cxf.common.util.ASMHelperImpl.getOpCodes(ASMHelperImpl.java:105)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:200)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> at
> org.apache.cxf.jaxws.spi.WrapperClassCreatorProxyService.generate(WrapperClassCreatorProxyService.java:40)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.createServer(CxfConsumer.java:75)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.doStart(CxfConsumer.java:107)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.startService(AbstractCamelContext.java:3760)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRouteConsumers(InternalRouteStartupManager.java:401)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartRouteConsumers(InternalRouteStartupManager.java:319)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.safelyStartRouteServices(InternalRouteStartupManager.java:213)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRoutes(InternalRouteStartupManager.java:147)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:3445)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:3114)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:3069)
> at
> org.apache.camel.spring.boot.SpringBootCamelContext.doStart(SpringBootCamelContext.java:43)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2718)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:262)
> at
> org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:119)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler$8.execute(CamelAnnotationsHandler.java:407)
> at
> org.apache.camel.test.spring.junit5.CamelSpringTestHelper.doToSpringCamelContexts(CamelSpringTestHelper.java:108)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler.handleCamelContextStartup(CamelAnnotationsHandler.java:400)
> at
>
