[jira] [Commented] (CXF-8896) http client sends some strange HTTP/1.1 and HTTP/2 mix headers
[
https://issues.apache.org/jira/browse/CXF-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740490#comment-17740490
]
Jim Ma commented on CXF-8896:
-
[~dkulp] Can we still get client use HTTP 1.1 by default without extra
configuration even if the server supports HTTP/2 ?
> http client sends some strange HTTP/1.1 and HTTP/2 mix headers
> --
>
> Key: CXF-8896
> URL: https://issues.apache.org/jira/browse/CXF-8896
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.2
>Reporter: Jim Ma
>Priority: Major
> Fix For: 4.0.3, 4.1.0
>
>
> From CXF 4.0.1, without the force http version with
>
> {code:java}
> ((BindingProvider)port).getRequestContext().put("org.apache.cxf.transport.http.forceVersion",
> "1.1"), {code}
> The http client sends request with strange headers :
> {code:java}
> POST /jaxws-securityDomain2/authz HTTP/1.1
> Connection: Upgrade, HTTP2-Settings
> Content-Length: 207
> Host: 127.0.0.1:23088
> HTTP2-Settings: AAEAAEIBAAMAAABkAAQBAAUAAEAA
> Upgrade: h2c
> Accept: */*
> Content-Type: text/xml; charset=UTF-8
> SOAPAction: ""
> User-Agent: Apache-CXF/4.0.1 {code}
> This works in CXF 4.0.0 and this commit seems introduce issue:
> [https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df]
>
> If force the HTTP/1.1 with property :
> org.apache.cxf.transport.http.forceVersion , it works. But this is a backward
> compatible issue and we should still support HTTP/1.1 by default.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8897) Several test steps fail when calling "mvn clean package verify" on CXF
[ https://issues.apache.org/jira/browse/CXF-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740532#comment-17740532 ] Mark Kahl commented on CXF-8897: [~reta], thanks: "install" works, and thank you for the "--fail-at-end" hint.. > Several test steps fail when calling "mvn clean package verify" on CXF > -- > > Key: CXF-8897 > URL: https://issues.apache.org/jira/browse/CXF-8897 > Project: CXF > Issue Type: Test > Components: Build system >Affects Versions: 4.0.2 > Environment: h1. OS > Distributor ID: Ubuntu > Description: Ubuntu 20.04.6 LTS > Release: 20.04 > Codename: focal > h1. Java/maven > Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f) > Maven home: /opt/maven > Java version: 17.0.7, vendor: Private Build, runtime: > /usr/lib/jvm/java-17-openjdk-amd64 > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "5.4.0-153-generic", arch: "amd64", family: "unix" >Reporter: Mark Kahl >Priority: Major > > When calling maven on the latest master of CXF several errors occur > Especially the first two issues are tricky because they only occur randomly, > but frequently. When both do not arise, other issues follow. However, the > latter can be solved by manual intervention. > h1. WaitForReceiveInMessage > This error only arises randomly but often. > * [ERROR] > org.apache.cxf.transport.jms.RequestResponseTest.testRequestTopicResponseStaticQueue > [ERROR] Run 1: > RequestResponseTest.testRequestTopicResponseStaticQueue:64->sendAndReceiveMessages:99->AbstractJMSTester.waitForReceiveInMessage:306 > Can't receive the Conduit Message in 10 seconds > [ERROR] Run 2: > RequestResponseTest.testRequestTopicResponseStaticQueue:64->sendAndReceiveMessages:99->AbstractJMSTester.waitForReceiveInMessage:306 > Can't receive the Conduit Message in 10 seconds > [ERROR] Run 3: > RequestResponseTest.testRequestTopicResponseStaticQueue:63->sendAndReceiveMessages:95->AbstractJMSTester.sendMessage:165->AbstractJMSTester.sendoutMessage:187 > » Runtime Timeout receiving messag\ > e with correlationId 966448dc1cb54df0b2da6654c31093810001 > [ERROR] Run 4: > RequestResponseTest.testRequestTopicResponseStaticQueue:64->sendAndReceiveMessages:99->AbstractJMSTester.waitForReceiveInMessage:306 > Can't receive the Conduit Message in 10 seconds > h1. Could not start Jetty server > This error only arises randomly but often. The port changes between calls, > the binding address is either: "0.0.0.0" or: "127.0.0.1" > * Could not start Jetty server on port 54,110: Failed to bind to > 0.0.0.0/0.0.0.0:54110 > h1. File in folder "/home/jenkins..." not found > A testing step fails because: > * > /home/jenkins/workspace/CXF/CXF-JDK17-deploy/testutils/src/main/resources/wsdl/hello_world_services.wsdl > was not found. This is normal IMHO, since not every machine features a user > called: "jenkins". When the appropriate folder is created and the file: > * testutils/src/main/resources/wsdl/hello_world_services.wsdl > is copied into it, the step succeeds. > h1. Folder > ~/.m2/repository/org/apache/cxf/org/apache/cxf/cxf-rt-transports-http missing > The sub-project: > * cxf-rt-transports-http > and all its files is created, however its content is not copied into the > local .m2-repository. Therefore, the following steps, that rely on its > content, fail. Manually copying the files into the local repository fixes > this issue: > * cp -rp > maven-plugins/wadl2java-plugin/target/it-repo/org/apache/cxf/cxf-rt-transports-http > ~/.m2/repository/org/apache/cxf/org/apache/cxf/cxf-rt-transports-http > h1. WSDL and XML files are missing in folder systests/transport-hc5 > The WSDL and XML files located in: > * testutils/target/classes/wsdl > are not copied to: > * systests/transport-hc5 > When copied manually the step succeeds: > * cp testutils/target/classes/wsdl/* systests/transport-hc5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8896) http client sends some strange HTTP/1.1 and HTTP/2 mix headers
[
https://issues.apache.org/jira/browse/CXF-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740589#comment-17740589
]
Daniel Kulp commented on CXF-8896:
--
It IS using HTTP 1.1 by default, but with the option to upgrade to HTTP/2.
The headers above are all valid HTTP 1.1 headers. If the server is rejecting
something in the above, that is a bug in the server, not CXF.
> http client sends some strange HTTP/1.1 and HTTP/2 mix headers
> --
>
> Key: CXF-8896
> URL: https://issues.apache.org/jira/browse/CXF-8896
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.2
>Reporter: Jim Ma
>Priority: Major
> Fix For: 4.0.3, 4.1.0
>
>
> From CXF 4.0.1, without the force http version with
>
> {code:java}
> ((BindingProvider)port).getRequestContext().put("org.apache.cxf.transport.http.forceVersion",
> "1.1"), {code}
> The http client sends request with strange headers :
> {code:java}
> POST /jaxws-securityDomain2/authz HTTP/1.1
> Connection: Upgrade, HTTP2-Settings
> Content-Length: 207
> Host: 127.0.0.1:23088
> HTTP2-Settings: AAEAAEIBAAMAAABkAAQBAAUAAEAA
> Upgrade: h2c
> Accept: */*
> Content-Type: text/xml; charset=UTF-8
> SOAPAction: ""
> User-Agent: Apache-CXF/4.0.1 {code}
> This works in CXF 4.0.0 and this commit seems introduce issue:
> [https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df]
>
> If force the HTTP/1.1 with property :
> org.apache.cxf.transport.http.forceVersion , it works. But this is a backward
> compatible issue and we should still support HTTP/1.1 by default.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8898) When using ASYNC Http Transport getting error in LoggingOutputStream "Encoding process already completed"
Juan Velez created CXF-8898:
---
Summary: 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
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.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:129)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:127)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:126)
at
org.junit.platform.eng
