[jira] [Created] (CXF-8988) Update to Spring Security 6.1.x release line
Andriy Redko created CXF-8988: - Summary: Update to Spring Security 6.1.x release line Key: CXF-8988 URL: https://issues.apache.org/jira/browse/CXF-8988 Project: CXF Issue Type: Improvement Affects Versions: 4.0.4 Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8963) URI is always unknown in server request metrics
[
https://issues.apache.org/jira/browse/CXF-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827942#comment-17827942
]
Andriy Redko commented on CXF-8963:
---
Thanks for confirming, [~fcurvat] !
> URI is always unknown in server request metrics
>
>
> Key: CXF-8963
> URL: https://issues.apache.org/jira/browse/CXF-8963
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3
>Reporter: Frédéric CURVAT
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.4
>
> Attachments: example.zip
>
>
> Since 4.0.0 (combined with spring boot 3.x), actuator prometheus -
> http_server_request - stats are not good anymore, they are missing the
> correct uri tag that is now always UNKNOWN.
> In 3.6.2 (combined with spring boot 2.7.x) this was working perfectly.
> Here attached a pet project to reproduce the issue.
> Run :
> {code:java}
> curl -s http://127.0.0.1:8080/services/sayHello/world
> curl -s http://127.0.0.1:8080/services/notFound
> Hello world, Welcome to CXF RS Spring Boot World!!!
> curl -s http://127.0.0.1:8080/actuator/prometheus | grep
> requests_seconds_count
> cxf_server_requests_seconds_count{exception="None",method="GET",operation="sayHello",outcome="SUCCESS",status="200",uri="/services/sayHello/
> {a}
> ",} 1.0
> http_server_requests_seconds_count
> {error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="UNKNOWN",}
> 1.0
> http_server_requests_seconds_count
> {error="none",excetpion="none",method="GET",outcome="CLIENT_ERROR",status="404",uri="NOT_FOUND",}
> 1.0
> {code}
>
> So cxf_server_requests are good but not http_server_requests
> Worth to notice there was a fix working a while ago :
> [https://github.com/apache/cxf/commit/cab4513374a14fd3549bd0cf86ef9b4996637546]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8986) Ws-security-policy: if more policies are used in the same JVM, their algorithm suites influence each other
[
https://issues.apache.org/jira/browse/CXF-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8986.
---
Resolution: Not A Problem
> Ws-security-policy: if more policies are used in the same JVM, their
> algorithm suites influence each other
> --
>
> Key: CXF-8986
> URL: https://issues.apache.org/jira/browse/CXF-8986
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 4.0.4
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I'm fixing some tests in quarkus-cxf and I found a behavior which seems to be
> not desired. On the other hand I might be missing some information and this
> behavior is expected.
> Reproducer:
> # Clone and build
> [https://github.com/JiriOndrusek/quarkus-cxf/tree/suite-influence-reprodocer]
> # Run (with remote debug)
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy
> -Dtest="EncryptSignPolicyTest#helloEncryptSign" -Dmaven.surefire.debug{code}
> Check value of effectivePolicy in this line
> [https://github.com/apache/cxf/blob/main/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/PolicyOutInterceptor.java#L98]
> Look into
> {code:java}
> effectivePolicy->policy->policyComponents->exactlyOne->policyComponents->all->policyComponents->asymmetricBinding->alghoritnSuite->alghorithSuiteType{code}
> Value is *Basic256*
> # Run different test by this command
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy
> -Dtest="CustomEncryptSignPolicyTest#helloDefaultCustomValues"
> -Dmaven.surefire.debug{code}
> Debug the same place and you can see, that the alghoritmSuiteType is
> *CustomAlgorithmSuite*
> # Now run both tests together by
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy
> -Dtest="EncryptSignPolicyTest#helloEncryptSign,CustomEncryptSignPolicyTest#helloDefaultCustomValues"
> -Dmaven.surefire.debug{code}
> The first breakpoint is triggered by
> {code:java}
> CustomEncryptSignPolicyTest#helloDefaultCustomValues{code}
> and you can see hat the alghoritmSuiteType is *CustomAlgorithmSuite*
> The second breakpoint belongs to
> {code:java}
> EncryptSignPolicyTest#helloEncryptSign{code}
> , but the value in the efectivePolicy->..->asymmetricBinding is
> *CustomAlgorithmSuite*
> This is wrong, the correct value should be *Basic256*
> I changed test `CustomEncryptSignPolicyTest#helloDefaultCustomValues` to use
> *Basic128Rsa15* (to verify that the culprit is not the customAlgorithmSuite)
> and the result was wrong as with default values.
> Single execution showed *Basic128Rsa15* or *Basic256* (depends on the test),
> but execution of both tests showed *Basic128Rsa15* in both cases.
> I think that the behavior is wrong. I have a test suite running on FIPS
> machine. If tests are executed alone all works correctly (some tests asserts
> success, some tests asserts failure). If I run tests together, the tests
> which should fail, are successful.
--
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]
Integration branch:
- [https://github.com/apache/cxf/tree/CXF-8671]
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 Processing 2.1*
* Jakarta J
[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)]
- 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]
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 Processing 2.1*
* Jakarta JSON Binding
[jira] [Updated] (CXF-8982) LoggingFeature does not hide sensitive xml elements with namespace prefix
[
https://issues.apache.org/jira/browse/CXF-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8982:
--
Fix Version/s: 3.5.9
4.0.5
3.6.4
> LoggingFeature does not hide sensitive xml elements with namespace prefix
> -
>
> Key: CXF-8982
> URL: https://issues.apache.org/jira/browse/CXF-8982
> Project: CXF
> Issue Type: Improvement
> Components: logging
>Affects Versions: 3.5.7, 3.6.2, 4.0.3
>Reporter: Gaëtan Pitteloud
>Priority: Major
> Fix For: 3.5.9, 4.0.5, 3.6.4
>
>
> When setting a sensitive element name in the LoggingFeature, the element is
> not hidden if the element appears in XML with a namespace prefix.
> It's not possible to just add a prefix when configuring the LoggingFeature:
> # this does not work for JSON
> # the namespace prefix is typically generated by the marshaller (ns1, ns2,
> etc) thus unknown during configuration
> The solution is to change the xml regex templates in MaskSensitiveHelper by
> adding the optional prefix group in the opening and closing tags:
>
> {code:java}
> private static final String MATCH_PATTERN_XML_TEMPLATE =
> "(<(\\w+:)?-ELEMENT_NAME-.*?>)(.*?)()";
> private static final String REPLACEMENT_XML_TEMPLATE = "$1XXX$4";
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8982) LoggingFeature does not hide sensitive xml elements with namespace prefix
[
https://issues.apache.org/jira/browse/CXF-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8982.
---
Resolution: Fixed
> LoggingFeature does not hide sensitive xml elements with namespace prefix
> -
>
> Key: CXF-8982
> URL: https://issues.apache.org/jira/browse/CXF-8982
> Project: CXF
> Issue Type: Improvement
> Components: logging
>Affects Versions: 3.5.7, 3.6.2, 4.0.3
>Reporter: Gaëtan Pitteloud
>Priority: Major
>
> When setting a sensitive element name in the LoggingFeature, the element is
> not hidden if the element appears in XML with a namespace prefix.
> It's not possible to just add a prefix when configuring the LoggingFeature:
> # this does not work for JSON
> # the namespace prefix is typically generated by the marshaller (ns1, ns2,
> etc) thus unknown during configuration
> The solution is to change the xml regex templates in MaskSensitiveHelper by
> adding the optional prefix group in the opening and closing tags:
>
> {code:java}
> private static final String MATCH_PATTERN_XML_TEMPLATE =
> "(<(\\w+:)?-ELEMENT_NAME-.*?>)(.*?)()";
> private static final String REPLACEMENT_XML_TEMPLATE = "$1XXX$4";
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8980) JaxRS client - receive timeout not working since CXF 4.0.1
[ https://issues.apache.org/jira/browse/CXF-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8980: -- Fix Version/s: 3.5.9 4.0.5 3.6.4 > JaxRS client - receive timeout not working since CXF 4.0.1 > -- > > Key: CXF-8980 > URL: https://issues.apache.org/jira/browse/CXF-8980 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 4.0.1, 4.0.2, 4.0.3 >Reporter: Emile de Weerd >Priority: Major > Fix For: 3.5.9, 4.0.5, 3.6.4 > > Attachments: cxf-4-receive-timeout-reproducer.zip > > > When the HTTP response returned is incomplete, i.e. a content-length header > is sent but the body sent is incomplete, since CXF 4.0.1 we can see that > there is no more a timeout and the following ProcessingException thrown. > It can be tested with this reproducer: > [^cxf-4-receive-timeout-reproducer.zip] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8976) Update to OpenTelemetry v1.36.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.36.0 (was: Update to OpenTelemetry
v1.35.0)
> Update to OpenTelemetry v1.36.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] (CXF-8982) LoggingFeature does not hide sensitive xml elements with namespace prefix
[
https://issues.apache.org/jira/browse/CXF-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8982:
--
Affects Version/s: 3.6.2
3.5.7
> LoggingFeature does not hide sensitive xml elements with namespace prefix
> -
>
> Key: CXF-8982
> URL: https://issues.apache.org/jira/browse/CXF-8982
> Project: CXF
> Issue Type: Improvement
> Components: logging
>Affects Versions: 3.5.7, 3.6.2, 4.0.3
>Reporter: Gaëtan Pitteloud
>Priority: Major
>
> When setting a sensitive element name in the LoggingFeature, the element is
> not hidden if the element appears in XML with a namespace prefix.
> It's not possible to just add a prefix when configuring the LoggingFeature:
> # this does not work for JSON
> # the namespace prefix is typically generated by the marshaller (ns1, ns2,
> etc) thus unknown during configuration
> The solution is to change the xml regex templates in MaskSensitiveHelper by
> adding the optional prefix group in the opening and closing tags:
>
> {code:java}
> private static final String MATCH_PATTERN_XML_TEMPLATE =
> "(<(\\w+:)?-ELEMENT_NAME-.*?>)(.*?)()";
> private static final String REPLACEMENT_XML_TEMPLATE = "$1XXX$4";
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823387#comment-17823387
]
Andriy Redko commented on CXF-8962:
---
[~freeman.fang] May I ask you please to backport this fix from main to 3.6.x,
I sadly won't have access to laptop till Friday. Thank you very much, really
appreciate it.
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
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&focusedCommentId=17821900#comment-17821900
]
Andriy Redko commented on CXF-8671:
---
Hey [~ohr] , the team is working on releases at the moment, but after that we
should get to [https://www.mail-archive.com/dev@cxf.apache.org/msg19805.html]
thread, thank you.
> 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.35.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] [Commented] (CXF-8900) cxf-xjc-plugin: code generated is half javax.xml.bind.annotation, half jakarta.xml.bind.annotation
[ https://issues.apache.org/jira/browse/CXF-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820899#comment-17820899 ] Andriy Redko commented on CXF-8900: --- [~minfrin] could you please provide the reproducer for the issue? on the other note, since you've upgrading the existing project, I assume that the project workspace has been cleaned up before the regeneration, is it a correct assumption? Thank you > cxf-xjc-plugin: code generated is half javax.xml.bind.annotation, half > jakarta.xml.bind.annotation > -- > > Key: CXF-8900 > URL: https://issues.apache.org/jira/browse/CXF-8900 > Project: CXF > Issue Type: Task > Components: JAXB Databinding > Environment: openjdk version "18.0.1.1" 2022-04-22 > OpenJDK Runtime Environment (build 18.0.1.1+2-6) > OpenJDK 64-Bit Server VM (build 18.0.1.1+2-6, mixed mode, sharing) >Reporter: Graham Leggett >Priority: Major > > When upgrading an otherwise working project to cxf-xjc-plugin v4.0.0, which > compiles a set of 17 XSD files into code, the resulting generated code has > some XSD code using the javax.xml.bind namespace, and other XSD code using > the jakarta.xml.bind namespace. > I was expecting one namespace or the other, but to see both namespaces used > apparently at random leaves me stuck. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8978) Codegen plugin fails with IBM JDK
[
https://issues.apache.org/jira/browse/CXF-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8978:
--
Fix Version/s: 4.0.4
> Codegen plugin fails with IBM JDK
> -
>
> Key: CXF-8978
> URL: https://issues.apache.org/jira/browse/CXF-8978
> Project: CXF
> Issue Type: Bug
> Components: Build system
>Affects Versions: 4.0.3
>Reporter: Thomas Egli
>Priority: Minor
> Fix For: 4.0.4
>
>
> With CXF-8912 the dependency to Xerces was removed. Alas, the Maven profile
> "ibmjdk" is still present in the codegen-plugin project, with a dependency to
> xercesImpl.
> Because the version information got removed, the dependency declaration is
> now invalid, and running the codegen-plugin with an IBM JDK now fails with:
> {{[ERROR] Plugin org.apache.cxf:cxf-codegen-plugin:4.0.3 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.cxf:cxf-codegen-plugin:jar:4.0.3: 1 problem was encountered while
> building the effective model for org.apache.cxf:cxf-codegen-plugin:4.0.3}}
> {{[ERROR] [ERROR] 'dependencies.dependency.version' for xerces:xercesImpl:jar
> is missing.}}
> Tested with IBM Semeru 17.
>
> We should remove this obsolete profile from the POM.
> As a workaround, one can override the "java.vendor" JVM property with
> something else than "IBM Corporation", e.g. {{-Djava.vendor=IBM Corp.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8978) Codegen plugin fails with IBM JDK
[
https://issues.apache.org/jira/browse/CXF-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8978.
---
Resolution: Fixed
> Codegen plugin fails with IBM JDK
> -
>
> Key: CXF-8978
> URL: https://issues.apache.org/jira/browse/CXF-8978
> Project: CXF
> Issue Type: Bug
> Components: Build system
>Affects Versions: 4.0.3
>Reporter: Thomas Egli
>Priority: Minor
> Fix For: 4.0.4
>
>
> With CXF-8912 the dependency to Xerces was removed. Alas, the Maven profile
> "ibmjdk" is still present in the codegen-plugin project, with a dependency to
> xercesImpl.
> Because the version information got removed, the dependency declaration is
> now invalid, and running the codegen-plugin with an IBM JDK now fails with:
> {{[ERROR] Plugin org.apache.cxf:cxf-codegen-plugin:4.0.3 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.cxf:cxf-codegen-plugin:jar:4.0.3: 1 problem was encountered while
> building the effective model for org.apache.cxf:cxf-codegen-plugin:4.0.3}}
> {{[ERROR] [ERROR] 'dependencies.dependency.version' for xerces:xercesImpl:jar
> is missing.}}
> Tested with IBM Semeru 17.
>
> We should remove this obsolete profile from the POM.
> As a workaround, one can override the "java.vendor" JVM property with
> something else than "IBM Corporation", e.g. {{-Djava.vendor=IBM Corp.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8956) include compiled WSDL in generated client
[ https://issues.apache.org/jira/browse/CXF-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8956. --- Resolution: Information Provided > include compiled WSDL in generated client > - > > Key: CXF-8956 > URL: https://issues.apache.org/jira/browse/CXF-8956 > Project: CXF > Issue Type: Improvement > Components: Core >Reporter: Mirza >Priority: Minor > > When I generate my client-package from the WSDL file, runtime still needs > access to WSDL file when accessing web service. This means I need to add WSDL > file to resources, and it gets more complicated when additional XSD files are > included in WSDL. > I think many people would prefer to have "compiled" version od WSDL (not > necessarily XML, maybe even JSON or whatever) inside generated Java client > package. It could be separate .java file with single static String containing > WSDL. This would be an option, like -embedWsdl. This would eliminate need for > resource WSDL files and simplify pom.xml file client generation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8956) include compiled WSDL in generated client
[ https://issues.apache.org/jira/browse/CXF-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819031#comment-17819031 ] Andriy Redko commented on CXF-8956: --- [~mirzac] so this functionality has been implemented to support, in particular, GraalVM native image packaging, please check out the documentation here [1] to find out the examples of how to capture generated classes and bundle them with your application. [1] https://cxf.apache.org/docs/graalvm-support.html > include compiled WSDL in generated client > - > > Key: CXF-8956 > URL: https://issues.apache.org/jira/browse/CXF-8956 > Project: CXF > Issue Type: Improvement > Components: Core >Reporter: Mirza >Priority: Minor > > When I generate my client-package from the WSDL file, runtime still needs > access to WSDL file when accessing web service. This means I need to add WSDL > file to resources, and it gets more complicated when additional XSD files are > included in WSDL. > I think many people would prefer to have "compiled" version od WSDL (not > necessarily XML, maybe even JSON or whatever) inside generated Java client > package. It could be separate .java file with single static String containing > WSDL. This would be an option, like -embedWsdl. This would eliminate need for > resource WSDL files and simplify pom.xml file client generation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8962:
--
Fix Version/s: 3.6.3
4.0.4
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8962:
--
Affects Version/s: 3.6.2
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8962:
-
Assignee: Andriy Redko
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8973) NettyHttpServerEngineFactory shuts down all netty instances when SpringContext is shutdown
[
https://issues.apache.org/jira/browse/CXF-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8973.
---
Resolution: Not A Problem
> NettyHttpServerEngineFactory shuts down all netty instances when
> SpringContext is shutdown
> --
>
> Key: CXF-8973
> URL: https://issues.apache.org/jira/browse/CXF-8973
> Project: CXF
> Issue Type: Bug
>Reporter: Eric
>Priority: Major
>
> {color:#00}NettyHttpServerEngineFactory{color} and
> {color:#00}{color:#00}JettyHttpServerEngineFactory are very similar
> in how they manage their ports and their lifecycle. There seems, however, to
> be minor difference in the Netty...Factory which seems to be the potential
> cause of bugs:
> {color}{color}
> {color:#00}{color:#00}{color:#00}
> {color}{color}{color}
> {code:java}
> class JettyHTTPServerEngineFactory {
> ...
> JettyHTTPServerEngineFactory(Bus bus) {
>setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, JettyHTTPServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(new
> JettyBusLifeCycleListener());
> }
> }
> }
> class JettyBusLifeCycleListener implements BusLifeCycleListener { ... }
> ...
> {code}
> {color:#00}{color:#00}vs{color}{color}
>
> {code:java}
> class NettyHttpServerEngineFactory implements BusLifeCycleListener {
> NettyHttpServerEngineFactory (Bus bus) {
> setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, NettyHttpServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(this);
> }
> }
> }
> ...
> {code}
> {color:#00}{color:#00}Both Variants seem to be very similar, however
> there is a subtle difference when it comes to this class:{color}{color}
>
> {code:java}
> class CXFBusLifeCycleManager implements BusLifeCycleManager {
> void initComplete() {
> if (bus != null){
> bus.getExtension(ConfiguredBeanLocator.class)
> .getBeansOfType(BusLifeCycleListener.class);
> }
> ...
> }
> ...
> }{code}
> {color:#00}{color:#00}Because NettyHttpServerEngineFactory implements
> BusLifeCycleListener, it can be found as an Extension in the
> LifeCycleManager, which cause the Constructor with the Bus Parameter to be
> call, which in turn automatically registers the Factory for automatic
> shutdown when a spring context is closed.{color}{color}
>
> {color:#00}{color:#00}This can have unexpected side-effects, when,
> for example in tests, Spring Contexts are created and destroyed on demand and
> combined with indendenpend server instances, like this:
> {color}{color}
> {code:java}
> class TestWithNetty {
> @BeforeAll
> static void setupServer() {
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(SomeWebResource.class);
> sf.setAddress("http://localhost:9000";);
> Server server = sf.create();
> }
> @RepeatedTest(2)
> void runtTestWithSpringContext(@Autowired ApplicationContextRunner runner) {
> runner.run(ctx -> // do something with spring context, calling
> localhost:9000);
> }
> }
> {code}
> {color:#00}{color:#00}This scenario, when called with a dependency on
> this works:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-jetty {code}
> {color:#00}{color:#00}That is, since netty is never registered as a
> outside of the beforeblock{color}{color}
>
>
> {color:#00}{color:#00}The same scenario with netty, however
> fails:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-netty-server {code}
> {color:#00}{color:#00}That is the Case because after the first test,
> the spring context is shutdown, which has the side effekt of destroying all
> netty servers, even those which where never managed by spring at all, simply
> because the constructor NettyHttpServerEngineFactory (Bus bus) was implicitly
> called by .getBeansOfType(BusLifeCycleListener.class), which registered the
> factory in the LifeCycle of the SpringBus{color}{color}
--
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.35.0+
- 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/])
- 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]
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 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
[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.35.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]
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 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*
*
[jira] [Created] (CXF-8976) Update to OpenTelemetry v1.35.0
Andriy Redko created CXF-8976:
-
Summary: Update to OpenTelemetry v1.35.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
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-8963) URI is always unknown in server request metrics
[
https://issues.apache.org/jira/browse/CXF-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8963.
---
Resolution: Fixed
> URI is always unknown in server request metrics
>
>
> Key: CXF-8963
> URL: https://issues.apache.org/jira/browse/CXF-8963
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3
>Reporter: Frédéric CURVAT
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.4
>
> Attachments: example.zip
>
>
> Since 4.0.0 (combined with spring boot 3.x), actuator prometheus -
> http_server_request - stats are not good anymore, they are missing the
> correct uri tag that is now always UNKNOWN.
> In 3.6.2 (combined with spring boot 2.7.x) this was working perfectly.
> Here attached a pet project to reproduce the issue.
> Run :
> {code:java}
> curl -s http://127.0.0.1:8080/services/sayHello/world
> curl -s http://127.0.0.1:8080/services/notFound
> Hello world, Welcome to CXF RS Spring Boot World!!!
> curl -s http://127.0.0.1:8080/actuator/prometheus | grep
> requests_seconds_count
> cxf_server_requests_seconds_count{exception="None",method="GET",operation="sayHello",outcome="SUCCESS",status="200",uri="/services/sayHello/
> {a}
> ",} 1.0
> http_server_requests_seconds_count
> {error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="UNKNOWN",}
> 1.0
> http_server_requests_seconds_count
> {error="none",excetpion="none",method="GET",outcome="CLIENT_ERROR",status="404",uri="NOT_FOUND",}
> 1.0
> {code}
>
> So cxf_server_requests are good but not http_server_requests
> Worth to notice there was a fix working a while ago :
> [https://github.com/apache/cxf/commit/cab4513374a14fd3549bd0cf86ef9b4996637546]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816407#comment-17816407
]
Andriy Redko edited comment on CXF-8962 at 2/11/24 1:07 PM:
Thanks for the update [~amichai]
> Thanks for the workaround! btw does anyone know in what version the
> workaround broke?
So it does not really broke, but 3.6.2+/ 4.0.1+switched to JDK-11 HttpClient
based conduit by default (so this setting does not apply there). But you still
have a choice to select the previous conduit (by setting another property) so
the things should continue working.
was (Author: reta):
Thanks for the update [~amichai]
> Thanks for the workaround! btw does anyone know in what version the
> workaround broke?
So it does not really broke, but 3.6.2+/ 4.0.1+switched to JDK-11 HttpClient
based conduit by default (so this setting does not apply there). But you still
have a choice to select the previous conduit (setting another property) so the
things should continue working.
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816407#comment-17816407
]
Andriy Redko commented on CXF-8962:
---
Thanks for the update [~amichai]
> Thanks for the workaround! btw does anyone know in what version the
> workaround broke?
So it does not really broke, but 3.6.2+/ 4.0.1+switched to JDK-11 HttpClient
based conduit by default (so this setting does not apply there). But you still
have a choice to select the previous conduit (setting another property) so the
things should continue working.
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816362#comment-17816362
]
Andriy Redko commented on CXF-8962:
---
[~amichai] Hm ... you could do it like that:
{noformat}
WebClient.getConfig(client).getRequestContext().put("set.content.type.for.empty.request",
true); {noformat}
{color:#00}which is actually equivalent to
client.getConfiguration().getRequestContext().put(...) {color}
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815872#comment-17815872
]
Andriy Redko edited comment on CXF-8962 at 2/9/24 12:10 AM:
[~amichai] you could set
`{color:#00}set.content.type.for.empty.request{color}` context property to
skip Content-Type header for empty request (for 3.5.x release branch).
was (Author: reta):
[~amichai] you could set
{color:#00}{color:#2a00ff}set.content.type.for.empty.request{color}{color}
context property to skip Content-Type header for empty request (for 3.5.x
release branch).
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815872#comment-17815872
]
Andriy Redko edited comment on CXF-8962 at 2/9/24 12:11 AM:
[~gchauvet] [~amichai] you could set
`{color:#00}set.content.type.for.empty.request{color}` context property to
`false to skip Content-Type header for empty request (for 3.5.x release branch).
was (Author: reta):
[~amichai] you could set
`{color:#00}set.content.type.for.empty.request{color}` context property to
`false to skip Content-Type header for empty request (for 3.5.x release branch).
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815872#comment-17815872
]
Andriy Redko edited comment on CXF-8962 at 2/9/24 12:10 AM:
[~amichai] you could set
`{color:#00}set.content.type.for.empty.request{color}` context property to
`false to skip Content-Type header for empty request (for 3.5.x release branch).
was (Author: reta):
[~amichai] you could set
`{color:#00}set.content.type.for.empty.request{color}` context property to
skip Content-Type header for empty request (for 3.5.x release branch).
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815872#comment-17815872
]
Andriy Redko edited comment on CXF-8962 at 2/9/24 12:11 AM:
[~gchauvet] [~amichai] you could set
`{color:#00}set.content.type.for.empty.request{color}` context property to
`false to skip Content-Type header for empty request (for < 3.6.x release
branches).
was (Author: reta):
[~gchauvet] [~amichai] you could set
`{color:#00}set.content.type.for.empty.request{color}` context property to
`false to skip Content-Type header for empty request (for 3.5.x release branch).
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815872#comment-17815872
]
Andriy Redko commented on CXF-8962:
---
[~amichai] you could set
{color:#00}{color:#2a00ff}set.content.type.for.empty.request{color}{color}
context property to skip Content-Type header for empty request (for 3.5.x
release branch).
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8972) Server exception raised when no Content-Type param provided
[
https://issues.apache.org/jira/browse/CXF-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814778#comment-17814778
]
Andriy Redko commented on CXF-8972:
---
[~yoshani] it all depends on how you configure your server: if your server
accept any content type (JAX-RS @Consumes annotation) than no, this is not
expected. If your server accepts some but the client sends something the server
does not understand than yes, it is expected.
> Server exception raised when no Content-Type param provided
> ---
>
> Key: CXF-8972
> URL: https://issues.apache.org/jira/browse/CXF-8972
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Yoshani Ranaweera
>Priority: Major
>
> If a request is sent without the Content-Type header parameter, a server
> exception _javax.ws.rs.WebApplicationException: HTTP 415 Unsupported Media
> Type_ is raised [1] and the below server error log is printed.
> _{org.apache.cxf.jaxrs.utils.JAXRSUtils} - No message body reader has been
> found for class java.lang.String, ContentType: application/octet-stream_
> Since this is a client error, it should not be handled as a server exception.
> [1]
> [https://github.com/apache/cxf/blob/main/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1581]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814532#comment-17814532
]
Andriy Redko commented on CXF-8975:
---
Cross posting from the pull request, as per rfc1341 (see please
https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html):
{noformat}
Overall, the body of a multipart entity may be specified as follows:
multipart-body := preamble 1*encapsulation
close-delimiter epilogue
encapsulation := delimiter CRLF body-part
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There must be no space
; between "--" and boundary.
close-delimiter := delimiter "--" ; Again, no space before
"--"
preamble := *text ; to be ignored upon
receipt.
epilogue := *text ; to be ignored upon
receipt.
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere. Note that the
semantics of a part differ from the semantics
of a message, as described in the text.>{noformat}
The element in question is
{noformat}
close-delimiter := delimiter "--" ; Again, no space before {noformat}
There should be a problem somewhere else I believe.
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Critical
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8975:
--
Priority: Minor (was: Critical)
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Minor
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <-- fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8975:
--
Priority: Major (was: Minor)
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Major
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <-- fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8963) URI is always unknown in server request metrics
[
https://issues.apache.org/jira/browse/CXF-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813441#comment-17813441
]
Andriy Redko commented on CXF-8963:
---
Thanks [~fcurvat] , the underlying mechanism has changed in Spring Boot 3
> URI is always unknown in server request metrics
>
>
> Key: CXF-8963
> URL: https://issues.apache.org/jira/browse/CXF-8963
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3
>Reporter: Frédéric CURVAT
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.4
>
> Attachments: example.zip
>
>
> Since 4.0.0 (combined with spring boot 3.x), actuator prometheus -
> http_server_request - stats are not good anymore, they are missing the
> correct uri tag that is now always UNKNOWN.
> In 3.6.2 (combined with spring boot 2.7.x) this was working perfectly.
> Here attached a pet project to reproduce the issue.
> Run :
> {code:java}
> curl -s http://127.0.0.1:8080/services/sayHello/world
> curl -s http://127.0.0.1:8080/services/notFound
> Hello world, Welcome to CXF RS Spring Boot World!!!
> curl -s http://127.0.0.1:8080/actuator/prometheus | grep
> requests_seconds_count
> cxf_server_requests_seconds_count{exception="None",method="GET",operation="sayHello",outcome="SUCCESS",status="200",uri="/services/sayHello/
> {a}
> ",} 1.0
> http_server_requests_seconds_count
> {error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="UNKNOWN",}
> 1.0
> http_server_requests_seconds_count
> {error="none",excetpion="none",method="GET",outcome="CLIENT_ERROR",status="404",uri="NOT_FOUND",}
> 1.0
> {code}
>
> So cxf_server_requests are good but not http_server_requests
> Worth to notice there was a fix working a while ago :
> [https://github.com/apache/cxf/commit/cab4513374a14fd3549bd0cf86ef9b4996637546]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8963) URI is always unknown in server request metrics
[
https://issues.apache.org/jira/browse/CXF-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8963:
-
Assignee: Andriy Redko
> URI is always unknown in server request metrics
>
>
> Key: CXF-8963
> URL: https://issues.apache.org/jira/browse/CXF-8963
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3
>Reporter: Frédéric CURVAT
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.4
>
> Attachments: example.zip
>
>
> Since 4.0.0 (combined with spring boot 3.x), actuator prometheus -
> http_server_request - stats are not good anymore, they are missing the
> correct uri tag that is now always UNKNOWN.
> In 3.6.2 (combined with spring boot 2.7.x) this was working perfectly.
> Here attached a pet project to reproduce the issue.
> Run :
> {code:java}
> curl -s http://127.0.0.1:8080/services/sayHello/world
> curl -s http://127.0.0.1:8080/services/notFound
> Hello world, Welcome to CXF RS Spring Boot World!!!
> curl -s http://127.0.0.1:8080/actuator/prometheus | grep
> requests_seconds_count
> cxf_server_requests_seconds_count{exception="None",method="GET",operation="sayHello",outcome="SUCCESS",status="200",uri="/services/sayHello/
> {a}
> ",} 1.0
> http_server_requests_seconds_count
> {error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="UNKNOWN",}
> 1.0
> http_server_requests_seconds_count
> {error="none",excetpion="none",method="GET",outcome="CLIENT_ERROR",status="404",uri="NOT_FOUND",}
> 1.0
> {code}
>
> So cxf_server_requests are good but not http_server_requests
> Worth to notice there was a fix working a while ago :
> [https://github.com/apache/cxf/commit/cab4513374a14fd3549bd0cf86ef9b4996637546]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8963) URI is always unknown in server request metrics
[
https://issues.apache.org/jira/browse/CXF-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8963:
--
Fix Version/s: 4.0.4
> URI is always unknown in server request metrics
>
>
> Key: CXF-8963
> URL: https://issues.apache.org/jira/browse/CXF-8963
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3
>Reporter: Frédéric CURVAT
>Priority: Major
> Fix For: 4.0.4
>
> Attachments: example.zip
>
>
> Since 4.0.0 (combined with spring boot 3.x), actuator prometheus -
> http_server_request - stats are not good anymore, they are missing the
> correct uri tag that is now always UNKNOWN.
> In 3.6.2 (combined with spring boot 2.7.x) this was working perfectly.
> Here attached a pet project to reproduce the issue.
> Run :
> {code:java}
> curl -s http://127.0.0.1:8080/services/sayHello/world
> curl -s http://127.0.0.1:8080/services/notFound
> Hello world, Welcome to CXF RS Spring Boot World!!!
> curl -s http://127.0.0.1:8080/actuator/prometheus | grep
> requests_seconds_count
> cxf_server_requests_seconds_count{exception="None",method="GET",operation="sayHello",outcome="SUCCESS",status="200",uri="/services/sayHello/
> {a}
> ",} 1.0
> http_server_requests_seconds_count
> {error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="UNKNOWN",}
> 1.0
> http_server_requests_seconds_count
> {error="none",excetpion="none",method="GET",outcome="CLIENT_ERROR",status="404",uri="NOT_FOUND",}
> 1.0
> {code}
>
> So cxf_server_requests are good but not http_server_requests
> Worth to notice there was a fix working a while ago :
> [https://github.com/apache/cxf/commit/cab4513374a14fd3549bd0cf86ef9b4996637546]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8893) Hard coded slashes at the end of SOAP namespaces are not always appreciated
[
https://issues.apache.org/jira/browse/CXF-8893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8893.
---
Resolution: Cannot Reproduce
[~agitatra] I am closing this issue for now, please feel free to reopen it and
provide reproducer, thank you.
> Hard coded slashes at the end of SOAP namespaces are not always appreciated
> ---
>
> Key: CXF-8893
> URL: https://issues.apache.org/jira/browse/CXF-8893
> Project: CXF
> Issue Type: Improvement
> Components: Core, JAX-WS Runtime
>Affects Versions: 4.0.2
>Reporter: Mark Kahl
>Priority: Major
>
> There are some functions that explicitly append a slash to URL's (see below),
> which is not always helpful. I have a client, unfortunately not under my
> jurisdiction, that refuses to work with my SOAP-service, since the service
> exports a WSDL-file, generated by CXF, that has a slash appended.
> I understand that just skipping the slash probably will affect a plethora of
> applications that rely on it, so maybe an option could be introduced
> modifying line 178 in the class: "PackageUtils" to:
> * return "http://"; + String.join(".", parts) + *((optionNoTrailingSlash) ?
> "" :* '/'{*}){*};
> instead of the current:
> * return "http://"; + String.join(".", parts) + '/';
> for example.
> h1. Statements that immutably append slashes
> The following list is the result of a regular expression search, probably not
> all of them are relevant.
> core/src/main/java/org/apache/cxf/common/util/PackageUtils.java:178:
> return "http://"; + String.join(".", parts) + '/';
> core/src/main/java/org/apache/cxf/helpers/ServiceUtils.java:211:
> return protocol + "://" + String.join(".", words) + "/";
> rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/NewCookieHeaderProvider.java:43:
> private static final String TSPECIALS_ALL = TSPECIALS_PATH + "/";
> rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriInfoImpl.java:230:
> address = address + "/";
> rt/rs/description-swagger-ui/src/main/java/org/apache/cxf/jaxrs/swagger/ui/SwaggerUiResolver.java:69:
> return urlStr + UI_RESOURCES_ROOT_START + version + "/";
> rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpUrlUtil.java:30:
> pathString = pathString + "/";
> systests/microprofile/client/jaxrs/src/test/java/org/apache/cxf/systest/microprofile/rest/client/regex/JaxrsPathRegexTest.java:76:
> String endpointAddress = "http://localhost:"; + PORT + "/";
> systests/microprofile/client/jaxrs/src/test/java/org/apache/cxf/systest/microprofile/rest/client/regex/JaxrsPathRegexTest.java:121:
> String endpointAddress = "http://localhost:"; + PORT + "/";
> systests/uncategorized/src/test/java/org/apache/cxf/systest/transform/feature/TransformFeatureTest.java:95:
> String endpoint = "http://127.0.0.1:"; + socket.getLocalPort() + "/";
> tools/corba/src/main/java/org/apache/cxf/tools/corba/processors/idl/ModuleToNSMapper.java:108:
> parentURI = parentURI + "/";
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8898) When using ASYNC Http Transport getting error in LoggingOutputStream "Encoding process already completed"
[
https://issues.apache.org/jira/browse/CXF-8898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8898.
---
Resolution: Cannot Reproduce
[~jveleztw] I am closing the issue , please feel free to reopen and provide
reproducer, thank you
> When using ASYNC Http Transport getting error in LoggingOutputStream
> "Encoding process already completed"
> -
>
> Key: CXF-8898
> URL: https://issues.apache.org/jira/browse/CXF-8898
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.6
>Reporter: Juan Velez
>Priority: Minor
>
> I am using CXF as a replacement for JAX-WS RI/RT and in that process I am
> porting our existing code to it. One of the things we don't like of JAX-WS
> RI/RT is the underlying use of HttpURLConnection so we wanted to try CXF with
> alternatives like Apache Http Components 4/5 or Netty. In testing any of
> these HTTP Transport alternatives (obviously with Async set to true,
> otherwise ends up using HttpURLConnection), we noticed that if my WS Client
> has been set up with either the LoggingFeature (e.g.
> {{{}jaxWsProxyFactoryBean.getFeatures().add(new LoggingFeature()){}}}) or via
> LoggingInterceptor (e.g.
> {{{}jaxWsProxyFactoryBean.getOutInterceptors().add(loggingOutInterceptor()){}}})
> when the client finishes there is an exception raised. If we removed the
> logging, no error is raised
> {code:java}
> javax.xml.ws.soap.SOAPFaultException: IllegalStateException invoking
> http://localhost:9090/codenotfound/ws/mm7: Encoding process already completed
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.mapException(JaxWsClientProxy.java:195)
>at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> at com.sun.proxy.$Proxy141.submit(Unknown Source) at
> com.codenotfound.SpringCxfApplicationTests.testMm7SubmitReq(SpringCxfApplicationTests.java:92)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
>at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
>at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
>at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:206)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:131)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:65)
>at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
>at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.N
[jira] [Resolved] (CXF-8904) TransformInInterceptor and SAAJInInterceptor - Getting SoapFault when accessing WSDL
[
https://issues.apache.org/jira/browse/CXF-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8904.
---
Resolution: Won't Fix
[~Sreeni] I am closing this one, please feel free to provide the reproducer but
it looks so far there is a body present.
> TransformInInterceptor and SAAJInInterceptor - Getting SoapFault when
> accessing WSDL
>
>
> Key: CXF-8904
> URL: https://issues.apache.org/jira/browse/CXF-8904
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.3
>Reporter: Sreenivas K
>Priority: Major
>
> Due to my peculiar usecase, i had to configure both
> *org.apache.cxf.feature.StaxTransformFeature (to transform namespaces) and
> SAAJInInterceptor* *(to modify soap body for a case).*
> But due to this, when i accessed webservice *?wsdl* in browser, its failing
> with below exception:
> _org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader._
> _at
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor$SAAJPreInInterceptor.handleMessage(SAAJInInterceptor.java:145)
> ~[cxf-rt-bindings-soap-3.5._
> _3.jar:3.5.3]_
> _Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog_
> _at [row,col
> {unknown-source}
> ]: [1,0]_
> _at
> com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:701)
> ~[woodstox-core-6.2.8.jar:6.2.8]_
> _at
> com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2235)
> ~[woodstox-core-6.2.8.jar:6.2.8]_
>
> When i looked into source code of
> _*org.apache.cxf.binding.soap.saaj.SAAJInInterceptor$SAAJPreInInterceptor,
> found below code to validate whether its GET request or not, which is failing
> and so it proceeded further and thrown that exception:*_
>
> {color:#00} {color}{color:#7f0055}public{color}{color:#00}
> {color}{color:#7f0055}boolean{color}{color:#00} isGET(T
> {color}{color:#6a3e3e}message{color}{color:#00}) {{color}
> {color:#00} String {color}{color:#6a3e3e}method{color}{color:#00} =
> (String)
> {color}{color:#6a3e3e}message{color}{color:#00}.get({color}{color:#2a00ff}"org.apache.cxf.request.method"{color}{color:#00});{color}
> {color:#00} {color}{color:#7f0055}return{color}{color:#00}
> {color}{color:#2a00ff}"GET"{color}{color:#00}.equals({color}{color:#6a3e3e}method{color}{color:#00})
> &&
> {color}{color:#6a3e3e}message{color}{color:#00}.{color}{color:#00}getContent{color}{color:#00}(XMLStreamReader.{color}{color:#7f0055}class{color}{color:#00})
> == {color}{color:#7f0055}null{color}{color:#00};{color}
> {color:#00} }{color}
> Here, this condition,
> *{color:#6a3e3e}message{color}{color:#00}.{color}{color:#00}getContent{color}{color:#00}(XMLStreamReader.{color}{color:#7f0055}class{color}{color:#00})
> == {color}{color:#7f0055}null,{color}* {color:#172b4d}is failing and reason
> i found is, its being set in *TransformInInterceptor,* which is gettng added
> to Interceptor Chain when *StaxTranformFeature* configured to cxf bus.{color}
> {color:#172b4d}To fix it (for now), i can remove that condition by extending
> the interceptor and overriding *isGET* method. But i just want to know is
> this expected or a bug ? And if i remove that condition, any other issues i
> may get? Or is there any other solution to address my problem?{color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8966) Failure to validate null xsd:int
[
https://issues.apache.org/jira/browse/CXF-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8966.
---
Resolution: Won't Fix
Closing this issue since the Woodstox fix is in progress
> Failure to validate null xsd:int
>
>
> Key: CXF-8966
> URL: https://issues.apache.org/jira/browse/CXF-8966
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.4.10, 3.5.5
>Reporter: François de Parscau
>Priority: Minor
>
> when a wsdl defines an element like this
> {code}
> minOccurs="0" >
> {code}
> and the resquest sent this element with a nil=true
> {code}
> http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/>
> {code}
> an exception is raised :
> {code}
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: Not a number: ?
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:931)
> ~[bundleFile:3.4.4]
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:737)
> ~[bundleFile:3.4.4]
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:170)
> ~[bundleFile:3.4.4]
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
> ~[bundleFile:3.4.4]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
[ https://issues.apache.org/jira/browse/CXF-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8974. --- Resolution: Not A Problem > remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is > superset > > > Key: CXF-8974 > URL: https://issues.apache.org/jira/browse/CXF-8974 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 4.0.3 >Reporter: JohnMTu >Priority: Minor > > From cxf-rt-bindings-soap i have on classpath > * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar > * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar > containing conflicting classes. Later one seems to be superset of first one. > Hence i suggest to remove earlier one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
[ https://issues.apache.org/jira/browse/CXF-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812438#comment-17812438 ] Andriy Redko commented on CXF-8974: --- No problem, please note that CXF 4.0.x officially supports Spring Boot 3.0.x, the upcoming 4.1.0 would support Spring Boot 3.2.x line > remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is > superset > > > Key: CXF-8974 > URL: https://issues.apache.org/jira/browse/CXF-8974 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 4.0.3 >Reporter: JohnMTu >Priority: Minor > > From cxf-rt-bindings-soap i have on classpath > * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar > * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar > containing conflicting classes. Later one seems to be superset of first one. > Hence i suggest to remove earlier one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
[ https://issues.apache.org/jira/browse/CXF-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812406#comment-17812406 ] Andriy Redko commented on CXF-8974: --- [~johnmtu] the 4.0.3 (and 4.0.x in general) does not import jakarta.xml.ws-api-4.0.1.jar (but 3.0.1 only), could you please share where the dependencies tree? Thank you. [1] https://mvnrepository.com/artifact/org.apache.cxf/cxf-rt-bindings-soap/4.0.3 > remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is > superset > > > Key: CXF-8974 > URL: https://issues.apache.org/jira/browse/CXF-8974 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 4.0.3 >Reporter: JohnMTu >Priority: Minor > > From cxf-rt-bindings-soap i have on classpath > * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar > * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar > containing conflicting classes. Later one seems to be superset of first one. > Hence i suggest to remove earlier one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8973) NettyHttpServerEngineFactory shuts down all netty instances when SpringContext is shutdown
[
https://issues.apache.org/jira/browse/CXF-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812317#comment-17812317
]
Andriy Redko commented on CXF-8973:
---
[~cheesemaster] AFAIK this is the intended (and desired) behavior when Apache
CXF is used with Spring Framework: when context shuts down, the registered
beans are destroyed. In this regards, the test does not look right to me - the
JAXRSServerFactoryBean should be a part of the application context (or part of
the parent application context), or alternately use the non-Spring aware Bus
instance in order to not interfere with the test at all.
> NettyHttpServerEngineFactory shuts down all netty instances when
> SpringContext is shutdown
> --
>
> Key: CXF-8973
> URL: https://issues.apache.org/jira/browse/CXF-8973
> Project: CXF
> Issue Type: Bug
>Reporter: Eric
>Priority: Major
>
> {color:#00}NettyHttpServerEngineFactory{color} and
> {color:#00}{color:#00}JettyHttpServerEngineFactory are very similar
> in how they manage their ports and their lifecycle. There seems, however, to
> be minor difference in the Netty...Factory which seems to be the potential
> cause of bugs:
> {color}{color}
> {color:#00}{color:#00}{color:#00}
> {color}{color}{color}
> {code:java}
> class JettyHTTPServerEngineFactory {
> ...
> JettyHTTPServerEngineFactory(Bus bus) {
>setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, JettyHTTPServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(new
> JettyBusLifeCycleListener());
> }
> }
> }
> class JettyBusLifeCycleListener implements BusLifeCycleListener { ... }
> ...
> {code}
> {color:#00}{color:#00}vs{color}{color}
>
> {code:java}
> class NettyHttpServerEngineFactory implements BusLifeCycleListener {
> NettyHttpServerEngineFactory (Bus bus) {
> setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, NettyHttpServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(this);
> }
> }
> }
> ...
> {code}
> {color:#00}{color:#00}Both Variants seem to be very similar, however
> there is a subtle difference when it comes to this class:{color}{color}
>
> {code:java}
> class CXFBusLifeCycleManager implements BusLifeCycleManager {
> void initComplete() {
> if (bus != null){
> bus.getExtension(ConfiguredBeanLocator.class)
> .getBeansOfType(BusLifeCycleListener.class);
> }
> ...
> }
> ...
> }{code}
> {color:#00}{color:#00}Because NettyHttpServerEngineFactory implements
> BusLifeCycleListener, it can be found as an Extension in the
> LifeCycleManager, which cause the Constructor with the Bus Parameter to be
> call, which in turn automatically registers the Factory for automatic
> shutdown when a spring context is closed.{color}{color}
>
> {color:#00}{color:#00}This can have unexpected side-effects, when,
> for example in tests, Spring Contexts are created and destroyed on demand and
> combined with indendenpend server instances, like this:
> {color}{color}
> {code:java}
> class TestWithNetty {
> @BeforeAll
> static void setupServer() {
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(SomeWebResource.class);
> sf.setAddress("http://localhost:9000";);
> Server server = sf.create();
> }
> @RepeatedTest(2)
> void runtTestWithSpringContext(@Autowired ApplicationContextRunner runner) {
> runner.run(ctx -> // do something with spring context, calling
> localhost:9000);
> }
> }
> {code}
> {color:#00}{color:#00}This scenario, when called with a dependency on
> this works:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-jetty {code}
> {color:#00}{color:#00}That is, since netty is never registered as a
> outside of the beforeblock{color}{color}
>
>
> {color:#00}{color:#00}The same scenario with netty, however
> fails:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-netty-server {code}
> {color:#00}{color:#00}That is the Case because after the first test,
> the spring context is shutdown, which has the side effekt of destroying all
> netty servers, even those which where never managed by spring at all, simply
> because the constructor NettyHttpServerEngineFactory (Bus bus) was implicit
[jira] [Commented] (CXF-8972) Server exception raised when no Content-Type param provided
[
https://issues.apache.org/jira/browse/CXF-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812307#comment-17812307
]
Andriy Redko commented on CXF-8972:
---
[~yoshani] please consult the HTTP 415 status code [1] description, it
describes the server role. Thank you
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
> Server exception raised when no Content-Type param provided
> ---
>
> Key: CXF-8972
> URL: https://issues.apache.org/jira/browse/CXF-8972
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Yoshani Ranaweera
>Priority: Major
>
> If a request is sent without the Content-Type header parameter, a server
> exception _javax.ws.rs.WebApplicationException: HTTP 415 Unsupported Media
> Type_ is raised [1] and the below server error log is printed.
> _{org.apache.cxf.jaxrs.utils.JAXRSUtils} - No message body reader has been
> found for class java.lang.String, ContentType: application/octet-stream_
> Since this is a client error, it should not be handled as a server exception.
> [1]
> [https://github.com/apache/cxf/blob/main/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1581]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8972) Server exception raised when no Content-Type param provided
[
https://issues.apache.org/jira/browse/CXF-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8972.
---
Resolution: Information Provided
> Server exception raised when no Content-Type param provided
> ---
>
> Key: CXF-8972
> URL: https://issues.apache.org/jira/browse/CXF-8972
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Yoshani Ranaweera
>Priority: Major
>
> If a request is sent without the Content-Type header parameter, a server
> exception _javax.ws.rs.WebApplicationException: HTTP 415 Unsupported Media
> Type_ is raised [1] and the below server error log is printed.
> _{org.apache.cxf.jaxrs.utils.JAXRSUtils} - No message body reader has been
> found for class java.lang.String, ContentType: application/octet-stream_
> Since this is a client error, it should not be handled as a server exception.
> [1]
> [https://github.com/apache/cxf/blob/main/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1581]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8955) Custom timeout with Message.RECEIVE_TIMEOUT not working with hc5 / hc
[
https://issues.apache.org/jira/browse/CXF-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8955.
---
Resolution: Fixed
> Custom timeout with Message.RECEIVE_TIMEOUT not working with hc5 / hc
> -
>
> Key: CXF-8955
> URL: https://issues.apache.org/jira/browse/CXF-8955
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.7, 3.6.2, 4.0.3
> Environment: Fedora 36, Java 17, cxf 4.0.3
>Reporter: Michael Wins
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: cxf_timeout_bug.tar-2.gz
>
>
> Hi, I am trying to set custom read timeouts for WS operations in an
> interceptor:
> {code:java}
> public class CustomReadTimeoutInterceptor extends
> AbstractPhaseInterceptor {
> ...
> @Override
> public void handleMessage(Message message) {
> message.put(Message.RECEIVE_TIMEOUT, timeoutMillis);
> }
> ...{code}
> That works well when using the JDK http client, but it does NOT work with the
> hc5 async client.
> It looks like requests issued in parallel affect each others timeout settings.
>
> Download the attached sample project, which contains a
> CustomReadTimeoutInterceptor and starts two requests in parallel with
> different timeouts (4 and 2 seconds).
> Execute both
> {code:java}
> mvn
> {code}
> and
> {code:java}
> mvn -DuseAsync
> {code}
> and compare the output. The output of the first will be like
> {code:java}
> CLIENT[19]: Duration: 2010 millis
> CLIENT[29]: Duration: 4211 millis{code}
> (which is as expected) whereas the second - using hc5 async - will result in
> {code:java}
> CLIENT[29]: Duration: 4269 millis
> CLIENT[19]: Duration: 4012 millis{code}
> Now I am wondering if my code is somehow incorrect or if it is cxf's fault...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809616#comment-17809616
]
Andriy Redko commented on CXF-8812:
---
Thank you for confirming
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8812.
---
Resolution: Fixed
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808713#comment-17808713
]
Andriy Redko commented on CXF-8812:
---
The new 3.5.8 snapshosts should be available now, thanks [~enrice]
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8812:
--
Fix Version/s: 3.5.8
3.6.3
4.0.4
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807923#comment-17807923
]
Andriy Redko commented on CXF-8812:
---
Thank you, I think I figured out the right place to have the headers filtered
out (limiting it to JAX-RS only), the pull request is out (if you could give it
a try before we merge it, would be much appreciated). Thank you.
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807236#comment-17807236
]
Andriy Redko commented on CXF-8812:
---
Thanks [~enrice] , could you please elaborate why "null" value of the header
does cause the issues for you? May be some examples of the code how you do
that may help (just trying to figure out if we have an opportunity to improve
the APIs there). Thank you.
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807007#comment-17807007
]
Andriy Redko commented on CXF-8812:
---
Hey [~enrice] ,
Thanks for reporting this behavior, what looked like a bug turned out to be
quite a designed behavior, there are 2 parts to this:
* the Content-Type header is indeed not send it the request, the CXF sets the
header to "null" (since headers are multivalues, it is represented as a
singleton list with "null" value)
* it is logical to assume that if header is not present, it should not be in
the list of headers (or at least have a "null" value), but the Content-Type is
used in many places and large number of critical paths rely on the presence of
the Content-Type header (not its value) for historical reasons, so removing it
breaks the existing applications
At the end, the value of the header is still "null":
{code:java}
String requestHeader = httpHeaders.getRequestHeader("Content-Type").get(0)
{code}
So the fact it is present as a collection with single "null" (even if not sent
in the request) could be a bit confusing / annoying at first, but it should not
lead to any behavior change.
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807007#comment-17807007
]
Andriy Redko edited comment on CXF-8812 at 1/16/24 2:02 AM:
Hey [~enrice] ,
Thanks for reporting this behavior, what looked like a bug turned out to be
quite a designed behavior, there are 2 parts to this:
* the Content-Type header is indeed not sent in the request, and the CXF sets
the header to "null" (since headers are multivalues, it is represented as a
singleton list with "null" value)
* it is logical to assume that if header is not present, it should not be in
the list of headers (or at least have a "null" value), but the Content-Type is
used in many places and large number of critical paths rely on the presence of
the Content-Type header (not its value) for historical reasons, so removing it
breaks the existing applications
At the end, the value of the header is still "null":
{code:java}
String requestHeader = httpHeaders.getRequestHeader("Content-Type").get(0)
{code}
So the fact it is present as a collection with single "null" (even if not sent
in the request) could be a bit confusing / annoying at first, but it should not
lead to any behavior change.
was (Author: reta):
Hey [~enrice] ,
Thanks for reporting this behavior, what looked like a bug turned out to be
quite a designed behavior, there are 2 parts to this:
* the Content-Type header is indeed not send it the request, the CXF sets the
header to "null" (since headers are multivalues, it is represented as a
singleton list with "null" value)
* it is logical to assume that if header is not present, it should not be in
the list of headers (or at least have a "null" value), but the Content-Type is
used in many places and large number of critical paths rely on the presence of
the Content-Type header (not its value) for historical reasons, so removing it
breaks the existing applications
At the end, the value of the header is still "null":
{code:java}
String requestHeader = httpHeaders.getRequestHeader("Content-Type").get(0)
{code}
So the fact it is present as a collection with single "null" (even if not sent
in the request) could be a bit confusing / annoying at first, but it should not
lead to any behavior change.
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8812:
--
Fix Version/s: (was: 3.5.8)
(was: 4.0.4)
(was: 3.6.3)
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8812) Content-Type header created with collection containing "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8812:
--
Summary: Content-Type header created with collection containing "null"
value (was: Content-Type header created with collection containg "null" value)
> Content-Type header created with collection containing "null" value
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8812) Content-Type header created with collection containg "null" value
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8812:
--
Summary: Content-Type header created with collection containg "null" value
(was: content-type header created on GET requests)
> Content-Type header created with collection containg "null" value
> -
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8812) content-type header created on GET requests
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8812:
--
Fix Version/s: 3.5.8
3.6.3
4.0.4
> content-type header created on GET requests
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8812) content-type header created on GET requests
[
https://issues.apache.org/jira/browse/CXF-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8812:
-
Assignee: Andriy Redko
> content-type header created on GET requests
> ---
>
> Key: CXF-8812
> URL: https://issues.apache.org/jira/browse/CXF-8812
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.5
> Environment: OpenJDK 1.8.0_352
> CentOS 7
> Tomcat 8.5.57
> Spring 4.3.30.RELEASE
> CXF 3.5.5
>Reporter: Erich Mauerböck
>Assignee: Andriy Redko
>Priority: Major
> Attachments: image-2023-01-22-13-04-32-164.png
>
>
> I have a simple REST web service method, deployed in tomcat, as follows:
> {code:java}
> @GET
> public void someMethod(@Context HttpHeaders httpHeaders) {
> ...
> } {code}
> When calling it, I get the following injected:
> !image-2023-01-22-13-04-32-164.png!
> I am expecting to get NO "Content-Type" header at all, because it hasn't been
> sent (verified by tcp dump).
> Btw. httpHeaders.getMediaType() works as expected (returning null) because it
> can cope with this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8969) Update to Brave 6
Andriy Redko created CXF-8969: - Summary: Update to Brave 6 Key: CXF-8969 URL: https://issues.apache.org/jira/browse/CXF-8969 Project: CXF Issue Type: Improvement Components: Tracing Brave Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 4.1.0 https://github.com/openzipkin/brave/releases/tag/6.0.0 -- 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 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) > 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 > > 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-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&focusedCommentId=17803719#comment-17803719 ] Andriy Redko commented on CXF-8951: --- [~lkoe] apologies, we need to [~dkulp] 's input as implementor of the feature (JDK's HttpClient) > 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 >Reporter: Lars Ködderitzsch >Priority: Blocker > 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-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 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) was: Support Jakarta EE 11 Minimum JDK requirement - JDK-17 Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) > 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 > > 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) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8834) "Operation [{.../wsdl}Issue] already exists" when calling JaxWsServerFactoryBean.create() for SecurityTokenService
[
https://issues.apache.org/jira/browse/CXF-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8834.
---
Resolution: Fixed
> "Operation [{.../wsdl}Issue] already exists" when calling
> JaxWsServerFactoryBean.create() for SecurityTokenService
> --
>
> Key: CXF-8834
> URL: https://issues.apache.org/jira/browse/CXF-8834
> Project: CXF
> Issue Type: Bug
> Components: STS
>Affects Versions: 4.0.0, 3.5.7, 3.6.2
>Reporter: Peter Palaga
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
>
> In quarkus-cxf, we are executing the following snippet
> {code}
> JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
> factoryBean.setServiceClass(Thread.currentThread().getContextClassLoader().loadClass(sei));
> factoryBean.setAddress(path);
> Server server = factoryBean.create();
> {code}
> for all service interfaces available in the class path of an application. We
> do it at build time, for the sake of generating all necessary ancillary
> classes.
> When doing this for
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}, the
> following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: An operation with name
> [{http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}Issue] already exists
> in this service
> at
> org.apache.cxf.service.model.InterfaceInfo.addOperation(InterfaceInfo.java:78)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createOperation(ReflectionServiceFactoryBean.java:1008)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.createOperation(JaxWsServiceFactoryBean.java:631)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createInterface(ReflectionServiceFactoryBean.java:1000)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:460)
> 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:210)
> at
> io.quarkiverse.cxf.deployment.CxfDeploymentUtils.createServer(CxfDeploymentUtils.java:42)
> at
> io.quarkiverse.cxf.deployment.QuarkusCxfProcessor.lambda$generateClasses$2(QuarkusCxfProcessor.java:213)
> ...
> {code}
> This is caused by the fact that there are two methods annotated with
> {{@WebMethod(operationName = "Issue")}} in
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}:
> {code}
> @WebResult(name = "RequestSecurityTokenResponseCollection",
>targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
>partName = "responseCollection")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseCollectionType issue(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> @WebResult(name = "RequestSecurityTokenResponse",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
> partName = "response")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseType issueSingle(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> {code}
> I wonder whether one of the operationNames in SecurityToke
[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: - Undertow 2.3.x - 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/)] - Hibernate 6.4 ([https://in.relation.to/2023/11/23/orm-640-final/|https://in.relation.to/2023/08/31/orm-630/]) - Weld 5 ([https://weld.cdi-spec.org/news/2022/04/29/weld-500Final/]) - 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]) - Spring Security 6.2 ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0]) - 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]) - Micrometer Tracing 1.2 ([https://github.com/micrometer-metrics/tracing/releases/tag/v1.1.4)] - 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] 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 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* * Ja
[jira] [Commented] (CXF-8898) When using ASYNC Http Transport getting error in LoggingOutputStream "Encoding process already completed"
[
https://issues.apache.org/jira/browse/CXF-8898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801270#comment-17801270
]
Andriy Redko commented on CXF-8898:
---
[~jveleztw] I was not able to reproduce the issue by modifying existing test
cases that use @XmlAttachmentRef and async client, could you please provide a
reproducer (or a test case)? Thank you.
> When using ASYNC Http Transport getting error in LoggingOutputStream
> "Encoding process already completed"
> -
>
> Key: CXF-8898
> URL: https://issues.apache.org/jira/browse/CXF-8898
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.6
>Reporter: Juan Velez
>Priority: Minor
>
> I am using CXF as a replacement for JAX-WS RI/RT and in that process I am
> porting our existing code to it. One of the things we don't like of JAX-WS
> RI/RT is the underlying use of HttpURLConnection so we wanted to try CXF with
> alternatives like Apache Http Components 4/5 or Netty. In testing any of
> these HTTP Transport alternatives (obviously with Async set to true,
> otherwise ends up using HttpURLConnection), we noticed that if my WS Client
> has been set up with either the LoggingFeature (e.g.
> {{{}jaxWsProxyFactoryBean.getFeatures().add(new LoggingFeature()){}}}) or via
> LoggingInterceptor (e.g.
> {{{}jaxWsProxyFactoryBean.getOutInterceptors().add(loggingOutInterceptor()){}}})
> when the client finishes there is an exception raised. If we removed the
> logging, no error is raised
> {code:java}
> javax.xml.ws.soap.SOAPFaultException: IllegalStateException invoking
> http://localhost:9090/codenotfound/ws/mm7: Encoding process already completed
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.mapException(JaxWsClientProxy.java:195)
>at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> at com.sun.proxy.$Proxy141.submit(Unknown Source) at
> com.codenotfound.SpringCxfApplicationTests.testMm7SubmitReq(SpringCxfApplicationTests.java:92)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
>at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
>at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
>at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:206)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:131)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:65)
>at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
>at
> org.junit.platform.engine.support.hierarchical
[jira] [Commented] (CXF-8893) Hard coded slashes at the end of SOAP namespaces are not always appreciated
[
https://issues.apache.org/jira/browse/CXF-8893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801263#comment-17801263
]
Andriy Redko commented on CXF-8893:
---
Hey [~agitatra] , I am not able to reproduce the issue (as I understand it) so
far: CXF preserves the exact namespaces as they are specified in WSDL file(s).
I would appreciate if you could submit a reporducer (or test case) that
demonstrates the issue. Thank you.
> Hard coded slashes at the end of SOAP namespaces are not always appreciated
> ---
>
> Key: CXF-8893
> URL: https://issues.apache.org/jira/browse/CXF-8893
> Project: CXF
> Issue Type: Improvement
> Components: Core, JAX-WS Runtime
>Affects Versions: 4.0.2
>Reporter: Mark Kahl
>Priority: Major
>
> There are some functions that explicitly append a slash to URL's (see below),
> which is not always helpful. I have a client, unfortunately not under my
> jurisdiction, that refuses to work with my SOAP-service, since the service
> exports a WSDL-file, generated by CXF, that has a slash appended.
> I understand that just skipping the slash probably will affect a plethora of
> applications that rely on it, so maybe an option could be introduced
> modifying line 178 in the class: "PackageUtils" to:
> * return "http://"; + String.join(".", parts) + *((optionNoTrailingSlash) ?
> "" :* '/'{*}){*};
> instead of the current:
> * return "http://"; + String.join(".", parts) + '/';
> for example.
> h1. Statements that immutably append slashes
> The following list is the result of a regular expression search, probably not
> all of them are relevant.
> core/src/main/java/org/apache/cxf/common/util/PackageUtils.java:178:
> return "http://"; + String.join(".", parts) + '/';
> core/src/main/java/org/apache/cxf/helpers/ServiceUtils.java:211:
> return protocol + "://" + String.join(".", words) + "/";
> rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/NewCookieHeaderProvider.java:43:
> private static final String TSPECIALS_ALL = TSPECIALS_PATH + "/";
> rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriInfoImpl.java:230:
> address = address + "/";
> rt/rs/description-swagger-ui/src/main/java/org/apache/cxf/jaxrs/swagger/ui/SwaggerUiResolver.java:69:
> return urlStr + UI_RESOURCES_ROOT_START + version + "/";
> rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpUrlUtil.java:30:
> pathString = pathString + "/";
> systests/microprofile/client/jaxrs/src/test/java/org/apache/cxf/systest/microprofile/rest/client/regex/JaxrsPathRegexTest.java:76:
> String endpointAddress = "http://localhost:"; + PORT + "/";
> systests/microprofile/client/jaxrs/src/test/java/org/apache/cxf/systest/microprofile/rest/client/regex/JaxrsPathRegexTest.java:121:
> String endpointAddress = "http://localhost:"; + PORT + "/";
> systests/uncategorized/src/test/java/org/apache/cxf/systest/transform/feature/TransformFeatureTest.java:95:
> String endpoint = "http://127.0.0.1:"; + socket.getLocalPort() + "/";
> tools/corba/src/main/java/org/apache/cxf/tools/corba/processors/idl/ModuleToNSMapper.java:108:
> parentURI = parentURI + "/";
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8834) "Operation [{.../wsdl}Issue] already exists" when calling JaxWsServerFactoryBean.create() for SecurityTokenService
[
https://issues.apache.org/jira/browse/CXF-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8834:
--
Affects Version/s: 3.6.2
3.5.7
> "Operation [{.../wsdl}Issue] already exists" when calling
> JaxWsServerFactoryBean.create() for SecurityTokenService
> --
>
> Key: CXF-8834
> URL: https://issues.apache.org/jira/browse/CXF-8834
> Project: CXF
> Issue Type: Bug
> Components: STS
>Affects Versions: 4.0.0, 3.5.7, 3.6.2
>Reporter: Peter Palaga
>Assignee: Andriy Redko
>Priority: Major
>
> In quarkus-cxf, we are executing the following snippet
> {code}
> JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
> factoryBean.setServiceClass(Thread.currentThread().getContextClassLoader().loadClass(sei));
> factoryBean.setAddress(path);
> Server server = factoryBean.create();
> {code}
> for all service interfaces available in the class path of an application. We
> do it at build time, for the sake of generating all necessary ancillary
> classes.
> When doing this for
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}, the
> following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: An operation with name
> [{http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}Issue] already exists
> in this service
> at
> org.apache.cxf.service.model.InterfaceInfo.addOperation(InterfaceInfo.java:78)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createOperation(ReflectionServiceFactoryBean.java:1008)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.createOperation(JaxWsServiceFactoryBean.java:631)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createInterface(ReflectionServiceFactoryBean.java:1000)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:460)
> 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:210)
> at
> io.quarkiverse.cxf.deployment.CxfDeploymentUtils.createServer(CxfDeploymentUtils.java:42)
> at
> io.quarkiverse.cxf.deployment.QuarkusCxfProcessor.lambda$generateClasses$2(QuarkusCxfProcessor.java:213)
> ...
> {code}
> This is caused by the fact that there are two methods annotated with
> {{@WebMethod(operationName = "Issue")}} in
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}:
> {code}
> @WebResult(name = "RequestSecurityTokenResponseCollection",
>targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
>partName = "responseCollection")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseCollectionType issue(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> @WebResult(name = "RequestSecurityTokenResponse",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
> partName = "response")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseType issueSingle(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> {code}
> I wonder whether one of the operationNames in SecurityTokenService ne
[jira] [Updated] (CXF-8834) "Operation [{.../wsdl}Issue] already exists" when calling JaxWsServerFactoryBean.create() for SecurityTokenService
[
https://issues.apache.org/jira/browse/CXF-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8834:
--
Fix Version/s: 3.5.8
3.6.3
4.0.4
> "Operation [{.../wsdl}Issue] already exists" when calling
> JaxWsServerFactoryBean.create() for SecurityTokenService
> --
>
> Key: CXF-8834
> URL: https://issues.apache.org/jira/browse/CXF-8834
> Project: CXF
> Issue Type: Bug
> Components: STS
>Affects Versions: 4.0.0, 3.5.7, 3.6.2
>Reporter: Peter Palaga
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
>
> In quarkus-cxf, we are executing the following snippet
> {code}
> JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
> factoryBean.setServiceClass(Thread.currentThread().getContextClassLoader().loadClass(sei));
> factoryBean.setAddress(path);
> Server server = factoryBean.create();
> {code}
> for all service interfaces available in the class path of an application. We
> do it at build time, for the sake of generating all necessary ancillary
> classes.
> When doing this for
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}, the
> following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: An operation with name
> [{http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}Issue] already exists
> in this service
> at
> org.apache.cxf.service.model.InterfaceInfo.addOperation(InterfaceInfo.java:78)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createOperation(ReflectionServiceFactoryBean.java:1008)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.createOperation(JaxWsServiceFactoryBean.java:631)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createInterface(ReflectionServiceFactoryBean.java:1000)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:460)
> 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:210)
> at
> io.quarkiverse.cxf.deployment.CxfDeploymentUtils.createServer(CxfDeploymentUtils.java:42)
> at
> io.quarkiverse.cxf.deployment.QuarkusCxfProcessor.lambda$generateClasses$2(QuarkusCxfProcessor.java:213)
> ...
> {code}
> This is caused by the fact that there are two methods annotated with
> {{@WebMethod(operationName = "Issue")}} in
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}:
> {code}
> @WebResult(name = "RequestSecurityTokenResponseCollection",
>targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
>partName = "responseCollection")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseCollectionType issue(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> @WebResult(name = "RequestSecurityTokenResponse",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
> partName = "response")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseType issueSingle(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> {code}
> I wonde
[jira] [Assigned] (CXF-8834) "Operation [{.../wsdl}Issue] already exists" when calling JaxWsServerFactoryBean.create() for SecurityTokenService
[
https://issues.apache.org/jira/browse/CXF-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-8834:
-
Assignee: Andriy Redko
> "Operation [{.../wsdl}Issue] already exists" when calling
> JaxWsServerFactoryBean.create() for SecurityTokenService
> --
>
> Key: CXF-8834
> URL: https://issues.apache.org/jira/browse/CXF-8834
> Project: CXF
> Issue Type: Bug
> Components: STS
>Affects Versions: 4.0.0
>Reporter: Peter Palaga
>Assignee: Andriy Redko
>Priority: Major
>
> In quarkus-cxf, we are executing the following snippet
> {code}
> JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
> factoryBean.setServiceClass(Thread.currentThread().getContextClassLoader().loadClass(sei));
> factoryBean.setAddress(path);
> Server server = factoryBean.create();
> {code}
> for all service interfaces available in the class path of an application. We
> do it at build time, for the sake of generating all necessary ancillary
> classes.
> When doing this for
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}, the
> following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: An operation with name
> [{http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}Issue] already exists
> in this service
> at
> org.apache.cxf.service.model.InterfaceInfo.addOperation(InterfaceInfo.java:78)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createOperation(ReflectionServiceFactoryBean.java:1008)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.createOperation(JaxWsServiceFactoryBean.java:631)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createInterface(ReflectionServiceFactoryBean.java:1000)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:460)
> 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:210)
> at
> io.quarkiverse.cxf.deployment.CxfDeploymentUtils.createServer(CxfDeploymentUtils.java:42)
> at
> io.quarkiverse.cxf.deployment.QuarkusCxfProcessor.lambda$generateClasses$2(QuarkusCxfProcessor.java:213)
> ...
> {code}
> This is caused by the fact that there are two methods annotated with
> {{@WebMethod(operationName = "Issue")}} in
> {{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}:
> {code}
> @WebResult(name = "RequestSecurityTokenResponseCollection",
>targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
>partName = "responseCollection")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseCollectionType issue(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> @WebResult(name = "RequestSecurityTokenResponse",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
> partName = "response")
> @Action(input =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
> output =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
> @WebMethod(operationName = "Issue")
> RequestSecurityTokenResponseType issueSingle(
> @WebParam(partName = "request",
> name = "RequestSecurityToken",
> targetNamespace =
> "http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
> RequestSecurityTokenType request
> );
> {code}
> I wonder whether one of the operationNames in SecurityTokenService needs to
> be changed?
--
This messa
[jira] [Commented] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801021#comment-17801021
]
Andriy Redko commented on CXF-8967:
---
[~ffang] I am wondering if you could look into this one, thank you!
> Body and elements not signed with security.enable.streaming = true
> --
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns";>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/";>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
> at
> io.quarkiverse.cxf.transport.CxfHandler.process(CxfHandler.java:241)
> at io.quarkiverse.cxf.transport.CxfHandler.h
[jira] [Resolved] (CXF-8968) OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a no-args constructor
[
https://issues.apache.org/jira/browse/CXF-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8968.
---
Resolution: Fixed
> OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a
> no-args constructor
> ---
>
> Key: CXF-8968
> URL: https://issues.apache.org/jira/browse/CXF-8968
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
>
> I am playing with the new OpenTelemetryClientFeature on Quarkus, where we
> typically produce CXF features as CDI beans. Quarkus CDI implementation does
> not allow beans of type OpenTelemetryClientFeature, because the class does
> not have the no-args constructor.
> We just need to add the default constructor, much like we already have it in
> OpenTelemetryFeature.
> A PR follows.
> For the sake of completeness here is the stack trace:
> {code}
> java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure:
> Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
> at
> io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
> at
> io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:474)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
> at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
> at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
> at
> org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
> at
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
> at java.base/java.lang.Thread.run(Thread.java:840)
> at org.jboss.threads.JBossThread.run(JBossThread.java:501)
> at
> io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:638)
> at
> io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:722)
> at java.base/java.util.Optional.orElseGet(Optional.java:364)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> Caused by: java.lang.RuntimeException: io.quarkus.builder.BuildException:
> Build failure: Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
> at
> io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
> at
> io.quarku
[jira] [Updated] (CXF-8968) OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a no-args constructor
[
https://issues.apache.org/jira/browse/CXF-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8968:
--
Issue Type: Improvement (was: Bug)
> OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a
> no-args constructor
> ---
>
> Key: CXF-8968
> URL: https://issues.apache.org/jira/browse/CXF-8968
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
>
> I am playing with the new OpenTelemetryClientFeature on Quarkus, where we
> typically produce CXF features as CDI beans. Quarkus CDI implementation does
> not allow beans of type OpenTelemetryClientFeature, because the class does
> not have the no-args constructor.
> We just need to add the default constructor, much like we already have it in
> OpenTelemetryFeature.
> A PR follows.
> For the sake of completeness here is the stack trace:
> {code}
> java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure:
> Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
> at
> io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
> at
> io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:474)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
> at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
> at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
> at
> org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
> at
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
> at java.base/java.lang.Thread.run(Thread.java:840)
> at org.jboss.threads.JBossThread.run(JBossThread.java:501)
> at
> io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:638)
> at
> io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:722)
> at java.base/java.util.Optional.orElseGet(Optional.java:364)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> Caused by: java.lang.RuntimeException: io.quarkus.builder.BuildException:
> Build failure: Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
> at
> io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
>
[jira] [Updated] (CXF-8968) OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a no-args constructor
[
https://issues.apache.org/jira/browse/CXF-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8968:
--
Fix Version/s: 3.5.8
3.6.3
4.0.4
> OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a
> no-args constructor
> ---
>
> Key: CXF-8968
> URL: https://issues.apache.org/jira/browse/CXF-8968
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
>
> I am playing with the new OpenTelemetryClientFeature on Quarkus, where we
> typically produce CXF features as CDI beans. Quarkus CDI implementation does
> not allow beans of type OpenTelemetryClientFeature, because the class does
> not have the no-args constructor.
> We just need to add the default constructor, much like we already have it in
> OpenTelemetryFeature.
> A PR follows.
> For the sake of completeness here is the stack trace:
> {code}
> java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure:
> Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
> at
> io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
> at
> io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:474)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
> at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
> at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
> at
> org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
> at
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
> at java.base/java.lang.Thread.run(Thread.java:840)
> at org.jboss.threads.JBossThread.run(JBossThread.java:501)
> at
> io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:638)
> at
> io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:722)
> at java.base/java.util.Optional.orElseGet(Optional.java:364)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> Caused by: java.lang.RuntimeException: io.quarkus.builder.BuildException:
> Build failure: Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
> at
> io.quarkus.arc.processor.BeanProcessor.validate(BeanPr
[jira] [Deleted] (CXF-8927) org.apache.cxf.systest.jaxrs.JAXRSMultipartTest crashes the JVM (JDK21 only)
[
https://issues.apache.org/jira/browse/CXF-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko deleted CXF-8927:
--
> org.apache.cxf.systest.jaxrs.JAXRSMultipartTest crashes the JVM (JDK21 only)
>
>
> Key: CXF-8927
> URL: https://issues.apache.org/jira/browse/CXF-8927
> Project: CXF
> Issue Type: Test
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
>
> For some reasons, the JDK 21 builds (both on 4.x and 3.6.x) ends with JDK-21
> JVM crash :
>
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.1.2:test (default-test) on
> project cxf-systests-jaxrs:
> [ERROR]
> [ERROR] Please refer to
> /home/jenkins/workspace/CXF/CXF-JDK21/systests/jaxrs/target/surefire-reports
> for the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was /bin/sh -c cd
> '/home/jenkins/workspace/CXF/CXF-JDK21/systests/jaxrs' &&
> '/usr/local/asfpackages/java/openjdk-21-ea+21/bin/java' '-ea' '--add-opens'
> 'java.base/java.lang=ALL-UNNAMED' '--add-opens'
> 'java.base/java.net=ALL-UNNAMED' '--add-opens'
> 'java.base/sun.net.www.protocol.https=ALL-UNNAMED' '-Dnone=' '-jar'
> '/home/jenkins/workspace/CXF/CXF-JDK21/systests/jaxrs/target/surefire/surefirebooter-20230908225402261_958.jar'
> '/home/jenkins/workspace/CXF/CXF-JDK21/systests/jaxrs/target/surefire'
> '2023-09-08T21-41-38_590-jvmRun1' 'surefire-20230908225402261_956tmp'
> 'surefire_170-20230908225402261_957tmp'
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 143
> [ERROR] Crashed tests:
> [ERROR] org.apache.cxf.systest.jaxrs.JAXRSMultipartTest
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or System.exit
> called?
> [ERROR] Command was /bin/sh -c cd
> '/home/jenkins/workspace/CXF/CXF-JDK21/systests/jaxrs' &&
> '/usr/local/asfpackages/java/openjdk-21-ea+21/bin/java' '-ea' '--add-opens'
> 'java.base/java.lang=ALL-UNNAMED' '--add-opens'
> 'java.base/java.net=ALL-UNNAMED' '--add-opens'
> 'java.base/sun.net.www.protocol.https=ALL-UNNAMED' '-Dnone=' '-jar'
> '/home/jenkins/workspace/CXF/CXF-JDK21/systests/jaxrs/target/surefire/surefirebooter-20230908225402261_958.jar'
> '/home/jenkins/workspace/CXF/CXF-JDK21/systests/jaxrs/target/surefire'
> '2023-09-08T21-41-38_590-jvmRun1' 'surefire-20230908225402261_956tmp'
> 'surefire_170-20230908225402261_957tmp'
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 143
> [ERROR] Crashed tests:
> [ERROR] org.apache.cxf.systest.jaxrs.JAXRSMultipartTest
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:643)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:285)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:250)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1203)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1055)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:871)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:328)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:316)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:75)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
> [ERROR] at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> [ERROR] at
[jira] [Updated] (CXF-8803) Support Dropwizard Metrics 5
[ https://issues.apache.org/jira/browse/CXF-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8803: -- Description: [https://github.com/dropwizard/metrics/releases/tag/v5.0.0-rc13] https://github.com/dropwizard/metrics/discussions/2932 was:https://github.com/dropwizard/metrics/releases/tag/v5.0.0-rc13 > Support Dropwizard Metrics 5 > > > Key: CXF-8803 > URL: https://issues.apache.org/jira/browse/CXF-8803 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.7.0, 4.1.0 > > > [https://github.com/dropwizard/metrics/releases/tag/v5.0.0-rc13] > https://github.com/dropwizard/metrics/discussions/2932 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8966) Failure to validate null xsd:int
[
https://issues.apache.org/jira/browse/CXF-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17797471#comment-17797471
]
Andriy Redko commented on CXF-8966:
---
Related to [https://github.com/FasterXML/woodstox/issues/179], seems to be MSV
related (not CXF or Woodstox)
> Failure to validate null xsd:int
>
>
> Key: CXF-8966
> URL: https://issues.apache.org/jira/browse/CXF-8966
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.4.10, 3.5.5
>Reporter: François de Parscau
>Priority: Minor
>
> when a wsdl defines an element like this
> {code}
> minOccurs="0" >
> {code}
> and the resquest sent this element with a nil=true
> {code}
> http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/>
> {code}
> an exception is raised :
> {code}
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: Not a number: ?
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:931)
> ~[bundleFile:3.4.4]
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:737)
> ~[bundleFile:3.4.4]
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:170)
> ~[bundleFile:3.4.4]
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
> ~[bundleFile:3.4.4]
> {code}
--
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: - Undertow 2.3.x - 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/)] - Hibernate 6.4 ([https://in.relation.to/2023/11/23/orm-640-final/|https://in.relation.to/2023/08/31/orm-630/]) - Weld 5 ([https://weld.cdi-spec.org/news/2022/04/29/weld-500Final/]) - 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]) - Spring Security 6.2 ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0]) - 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]) - Micrometer Tracing 1.2 ([https://github.com/micrometer-metrics/tracing/releases/tag/v1.1.4)] - 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]) - 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] 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: * 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 En
[jira] [Resolved] (CXF-8965) Apache CXF Netty Integration, URI not encoded
[ https://issues.apache.org/jira/browse/CXF-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8965. --- Resolution: Fixed > Apache CXF Netty Integration, URI not encoded > - > > Key: CXF-8965 > URL: https://issues.apache.org/jira/browse/CXF-8965 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.5.7, 3.6.2, 4.0.3 >Reporter: Jochen Wilhelm >Priority: Minor > Fix For: 3.5.8, 3.6.3, 4.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > There is an issue when using Apache CXF with Netty. It seems that URI > encoding of pathes, e.g. containing whitespaces doesn't work. > The suspect org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest > line 57 to be the problem. > There the request uri is past but with uri.getPath() which decodes the URI, > instead using uri.getRawPath() should be used. > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getPath(), content); > instead using > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getRawPath(), content); > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8964) Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on
[ https://issues.apache.org/jira/browse/CXF-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8964. --- Resolution: Fixed > Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on > --- > > Key: CXF-8964 > URL: https://issues.apache.org/jira/browse/CXF-8964 > Project: CXF > Issue Type: Bug >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.4 > > > Addressing multiple CVEs reports -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8965) Apache CXF Netty Integration, URI not encoded
[ https://issues.apache.org/jira/browse/CXF-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8965: -- Priority: Minor (was: Major) > Apache CXF Netty Integration, URI not encoded > - > > Key: CXF-8965 > URL: https://issues.apache.org/jira/browse/CXF-8965 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.5.7, 3.6.2, 4.0.3 >Reporter: Jochen Wilhelm >Priority: Minor > Fix For: 3.5.8, 3.6.3, 4.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > There is an issue when using Apache CXF with Netty. It seems that URI > encoding of pathes, e.g. containing whitespaces doesn't work. > The suspect org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest > line 57 to be the problem. > There the request uri is past but with uri.getPath() which decodes the URI, > instead using uri.getRawPath() should be used. > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getPath(), content); > instead using > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getRawPath(), content); > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8965) Apache CXF Netty Integration, URI not encoded
[ https://issues.apache.org/jira/browse/CXF-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8965: -- Affects Version/s: 4.0.3 3.6.2 3.5.7 > Apache CXF Netty Integration, URI not encoded > - > > Key: CXF-8965 > URL: https://issues.apache.org/jira/browse/CXF-8965 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.5.7, 3.6.2, 4.0.3 >Reporter: Jochen Wilhelm >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > There is an issue when using Apache CXF with Netty. It seems that URI > encoding of pathes, e.g. containing whitespaces doesn't work. > The suspect org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest > line 57 to be the problem. > There the request uri is past but with uri.getPath() which decodes the URI, > instead using uri.getRawPath() should be used. > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getPath(), content); > instead using > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getRawPath(), content); > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8965) Apache CXF Netty Integration, URI not encoded
[ https://issues.apache.org/jira/browse/CXF-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8965: -- Fix Version/s: 3.5.8 3.6.3 4.0.4 > Apache CXF Netty Integration, URI not encoded > - > > Key: CXF-8965 > URL: https://issues.apache.org/jira/browse/CXF-8965 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: Jochen Wilhelm >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > There is an issue when using Apache CXF with Netty. It seems that URI > encoding of pathes, e.g. containing whitespaces doesn't work. > The suspect org.apache.cxf.transport.http.netty.client.NettyHttpClientRequest > line 57 to be the problem. > There the request uri is past but with uri.getPath() which decodes the URI, > instead using uri.getRawPath() should be used. > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getPath(), content); > instead using > this.request = > new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, > HttpMethod.valueOf(method), > uri.getRawPath(), content); > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8964) Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on
[ https://issues.apache.org/jira/browse/CXF-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8964: -- Fix Version/s: 3.5.8 3.6.3 4.0.4 > Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on > --- > > Key: CXF-8964 > URL: https://issues.apache.org/jira/browse/CXF-8964 > Project: CXF > Issue Type: Bug >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.4 > > > Addressing multiple CVEs reports -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8964) Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on
Andriy Redko created CXF-8964: - Summary: Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on Key: CXF-8964 URL: https://issues.apache.org/jira/browse/CXF-8964 Project: CXF Issue Type: Bug Reporter: Andriy Redko Assignee: Andriy Redko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8964) Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on
[ https://issues.apache.org/jira/browse/CXF-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8964: -- Description: Addressing multiple CVEs reports > Update Bouncycastle from unsupported xxx-jdk15on to xxx-jdk18on > --- > > Key: CXF-8964 > URL: https://issues.apache.org/jira/browse/CXF-8964 > Project: CXF > Issue Type: Bug >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > > Addressing multiple CVEs reports -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8953) Better support of the HTTPS protocol versions used by client/server conduits
[ https://issues.apache.org/jira/browse/CXF-8953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8953. --- Resolution: Fixed > Better support of the HTTPS protocol versions used by client/server conduits > > > Key: CXF-8953 > URL: https://issues.apache.org/jira/browse/CXF-8953 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.5.7, 3.6.2, 4.0.3 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.4 > > > Undertow server conduit does not support TLSv1.3 (see please > https://issues.apache.org/jira/browse/CXF-8952?focusedCommentId=17782106&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17782106) > The HTTP client conduits should consult *https.protocols* system property > (see please [https://blogs.oracle.com/java/post/diagnosing-tls-ssl-and-https]) > > Documentation update: > https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Client+API#JAXRSClientAPI-ClientsandHTTP(s) -- 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&focusedCommentId=17790734#comment-17790734
]
Andriy Redko commented on CXF-8951:
---
> However, due to some reflection hacks to allow for PATCH methods with
> HttpURLConnection in cxf, this requires additional JVM args to be set in Java
> 17+ ("--add-opens", "java.base/java.net=ALL-UNNAMED").
Correct, this is sadly a trade-off (for the time being), thank you
> 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
>Reporter: Lars Ködderitzsch
>Priority: Blocker
> 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] [Comment Edited] (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&focusedCommentId=17790559#comment-17790559 ] Andriy Redko edited comment on CXF-8951 at 11/28/23 1:14 PM: - [~lkoe] I am unsure if [~dkulp] looked at it yet, but there is another option to mitigate the problem: new Bus / system property "org.apache.cxf.transport.http.forceURLConnection" that allows to fallback to the old HttpConduit altogether, see please [https://github.com/apache/cxf/commit/3d70de80fb60b74040c0214fc6a28774362556e4|https://github.com/apache/cxf/commit/3d70de80fb60b74040c0214fc6a28774362556e4.], not a solution obviously but workaround for the time being, thank you was (Author: reta): [~lkoe] I am unsure if [~dkulp] looked at it, but there is another option to mitigate the problem: new Bus / system property "org.apache.cxf.transport.http.forceURLConnection" that allows to fallback to the old HttpConduit altogether, see please [https://github.com/apache/cxf/commit/3d70de80fb60b74040c0214fc6a28774362556e4|https://github.com/apache/cxf/commit/3d70de80fb60b74040c0214fc6a28774362556e4.], not a solution obviously but workaround for the time being, thank you > 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 >Reporter: Lars Ködderitzsch >Priority: Blocker > 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&focusedCommentId=17790559#comment-17790559 ] Andriy Redko commented on CXF-8951: --- [~lkoe] I am unsure if [~dkulp] looked at it, but there is another option to mitigate the problem: new Bus / system property "org.apache.cxf.transport.http.forceURLConnection" that allows to fallback to the old HttpConduit altogether, see please [https://github.com/apache/cxf/commit/3d70de80fb60b74040c0214fc6a28774362556e4|https://github.com/apache/cxf/commit/3d70de80fb60b74040c0214fc6a28774362556e4.], not a solution obviously but workaround for the time being, thank you > 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 >Reporter: Lars Ködderitzsch >Priority: Blocker > 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-8953) Better support of the HTTPS protocol versions used by client/server conduits
[ https://issues.apache.org/jira/browse/CXF-8953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8953: -- Description: Undertow server conduit does not support TLSv1.3 (see please https://issues.apache.org/jira/browse/CXF-8952?focusedCommentId=17782106&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17782106) The HTTP client conduits should consult *https.protocols* system property (see please [https://blogs.oracle.com/java/post/diagnosing-tls-ssl-and-https]) Documentation update: https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Client+API#JAXRSClientAPI-ClientsandHTTP(s) was: Undertow server conduit does not support TLSv1.3 (see please https://issues.apache.org/jira/browse/CXF-8952?focusedCommentId=17782106&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17782106) The HTTP client conduits should consult *https.protocols* system property (see please https://blogs.oracle.com/java/post/diagnosing-tls-ssl-and-https) > Better support of the HTTPS protocol versions used by client/server conduits > > > Key: CXF-8953 > URL: https://issues.apache.org/jira/browse/CXF-8953 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.5.7, 3.6.2, 4.0.3 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.4 > > > Undertow server conduit does not support TLSv1.3 (see please > https://issues.apache.org/jira/browse/CXF-8952?focusedCommentId=17782106&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17782106) > The HTTP client conduits should consult *https.protocols* system property > (see please [https://blogs.oracle.com/java/post/diagnosing-tls-ssl-and-https]) > > Documentation update: > https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Client+API#JAXRSClientAPI-ClientsandHTTP(s) -- 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: * 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: - Undertow 2.3.x - 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/)] - Hibernate 6.4 ([https://in.relation.to/2023/11/23/orm-640-final/|https://in.relation.to/2023/08/31/orm-630/]) - Weld 5 ([https://weld.cdi-spec.org/news/2022/04/29/weld-500Final/]) - 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]) - Spring Security 6.2 ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0]) - 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]) - Micrometer Tracing 1.2 ([https://github.com/micrometer-metrics/tracing/releases/tag/v1.1.4)] - 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]) - 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] 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: * 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
[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: * 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: - Undertow 2.3.x - 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/)] - Hibernate 6.4 ([https://in.relation.to/2023/08/31/orm-630/]) - Weld 5 ([https://weld.cdi-spec.org/news/2022/04/29/weld-500Final/]) - 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]) - Spring Security 6.2 ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0]) - 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]) - Micrometer Tracing 1.2 ([https://github.com/micrometer-metrics/tracing/releases/tag/v1.1.4)] - 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]) - 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] 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: * 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: - [
[jira] [Commented] (CXF-8932) [WSDL2JAVA] Not working on JDK11
[
https://issues.apache.org/jira/browse/CXF-8932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788929#comment-17788929
]
Andriy Redko commented on CXF-8932:
---
Hi [~Spoor] , I believe there is high chance to have the release before end of
the year, thank you.
> [WSDL2JAVA] Not working on JDK11
>
>
> Key: CXF-8932
> URL: https://issues.apache.org/jira/browse/CXF-8932
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Laurent SCHOELENS
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.4
>
> Attachments: cxf-8932.zip, image-2023-09-21-07-39-06-219.png
>
>
>
> I get the following error when running wsdl2java with cxf 4.0.3 and jdk11 :
> {code:java}
> [WARNING] Exception in thread "main" java.lang.UnsupportedClassVersionError:
> org/springframework/context/ApplicationContext has been compiled by a more
> recent version of the Java Runtime (class file version 61.0), this version of
> the Java Runtime only recognizes class file versions up to 55.0
> [WARNING] at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> [WARNING] at
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> [WARNING] at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
> [WARNING] at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
> [WARNING] at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
> [WARNING] at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
> [WARNING] at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
> [WARNING] at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> [WARNING] at
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> [WARNING] at
> org.apache.cxf.BusFactory.getBusFactoryClass(BusFactory.java:392)
> [WARNING] at org.apache.cxf.BusFactory.newInstance(BusFactory.java:315)
> [WARNING] at org.apache.cxf.BusFactory.newInstance(BusFactory.java:303)
> [WARNING] at org.apache.cxf.BusFactory.getDefaultBus(BusFactory.java:107)
> [WARNING] at org.apache.cxf.BusFactory.getDefaultBus(BusFactory.java:96)
> {code}
> It seems CXF tries to load org.apache.cxf.bus.spring.SpringBusFactory as
> default BusFactory (defined here
> {color:#1d1c1d}cxf-core-4.0.3.jar!/META-INF/services/org.apache.cxf.bus.factory)
> but with spring jdk17 baseline, it fails.{color}
> CXF should not use SpringBusFactory if intended to support JDK11+
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8961) java.io.EOFException when consuming SOAP webservice using cxf 3.6.2
[
https://issues.apache.org/jira/browse/CXF-8961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8961:
--
Affects Version/s: 4.0.3
> java.io.EOFException when consuming SOAP webservice using cxf 3.6.2
> ---
>
> Key: CXF-8961
> URL: https://issues.apache.org/jira/browse/CXF-8961
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Gijs Muys
>Priority: Major
>
> I am using cxf 3.6.2 to generate java classes based on a wsdl and I'm then
> invoking the SOAP webservice using these generated java classes. This works
> but regularly I get the following exception:
>
> {code:java}
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67)
> ~[cxf-core-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-3.6.2.jar:3.6.2]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:528)
> ~[cxf-core-3.6.2.jar:3.6.2]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:439)
> ~[cxf-core-3.6.2.jar:3.6.2]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:354)
> ~[cxf-core-3.6.2.jar:3.6.2]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:312)
> ~[cxf-core-3.6.2.jar:3.6.2]
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> ~[cxf-rt-frontend-simple-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
> ~[cxf-rt-frontend-jaxws-3.6.2.jar:3.6.2]
> at com.sun.proxy.$Proxy73.rltpreval(Unknown Source) ~[na:na]
> at com.example.demo.Blabla.onApplicationEvent(Blabla.java:46) ~[main/:na]
> at com.example.demo.Blabla.onApplicationEvent(Blabla.java:15) ~[main/:na]
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:178)
> ~[spring-context-5.3.30.jar:5.3.30]
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:171)
> ~[spring-context-5.3.30.jar:5.3.30]
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:145)
> ~[spring-context-5.3.30.jar:5.3.30]
> at
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:421)
> ~[spring-context-5.3.30.jar:5.3.30]
> at
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:378)
> ~[spring-context-5.3.30.jar:5.3.30]
> at
> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:941)
> ~[spring-context-5.3.30.jar:5.3.30]
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:586)
> ~[spring-context-5.3.30.jar:5.3.30]
> at
> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:732)
> ~[spring-boot-2.7.17.jar:2.7.17]
> at
> org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:409)
> ~[spring-boot-2.7.17.jar:2.7.17]
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:308)
> ~[spring-boot-2.7.17.jar:2.7.17]
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1300)
> ~[spring-boot-2.7.17.jar:2.7.17]
> at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:1289)
> ~[spring-boot-2.7.17.jar:2.7.17]
> at com.example.demo.DemoApplication.main(DemoApplication.java:14)
> ~[main/:na]
> Caused by: java.io.IOException: IOException invoking myurl:myport?wsdl:
> HTTP/1.1 header parser received no bytes
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) ~[na:na]
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> ~[na:na]
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> ~[na:na]
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> ~[na:na]
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1452)
> ~[cxf-rt-transports-http-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1433)
> ~[cxf-rt-transports-http-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputS
