[jira] [Resolved] (CXF-8997) AbstractSTSTokenTest and TransportBindingTests no longer need to set https protocol to TLSv1 on IBM Java
[ https://issues.apache.org/jira/browse/CXF-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8997. --- Resolution: Fixed > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java > > > Key: CXF-8997 > URL: https://issues.apache.org/jira/browse/CXF-8997 > Project: CXF > Issue Type: Test > Components: STS >Affects Versions: 3.6.3, 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Major > Fix For: 4.0.5, 3.6.4 > > > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java. > Current builds of CXF 4.0.x on IBM Java will fail the AbstractSTSTokenTest > and TransportBindingTests due to their use of TLSv1. Note: IBM JDKs disable > TLSv1 by default since around Java 8 > (https://community.ibm.com/community/user/wasdevops/blogs/hiroko-takamiya1/2021/06/19/ibm-java-80630-disables-tlsv1-tlsv11-by-default-ho). > Removing the test case IBM control flag allows the default TLS to pass the > tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8997) AbstractSTSTokenTest and TransportBindingTests no longer need to set https protocol to TLSv1 on IBM Java
[ https://issues.apache.org/jira/browse/CXF-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8997: -- Fix Version/s: 3.6.4 > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java > > > Key: CXF-8997 > URL: https://issues.apache.org/jira/browse/CXF-8997 > Project: CXF > Issue Type: Test > Components: STS >Affects Versions: 3.6.3, 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Major > Fix For: 4.0.5, 3.6.4 > > > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java. > Current builds of CXF 4.0.x on IBM Java will fail the AbstractSTSTokenTest > and TransportBindingTests due to their use of TLSv1. Note: IBM JDKs disable > TLSv1 by default since around Java 8 > (https://community.ibm.com/community/user/wasdevops/blogs/hiroko-takamiya1/2021/06/19/ibm-java-80630-disables-tlsv1-tlsv11-by-default-ho). > Removing the test case IBM control flag allows the default TLS to pass the > tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8997) AbstractSTSTokenTest and TransportBindingTests no longer need to set https protocol to TLSv1 on IBM Java
[ https://issues.apache.org/jira/browse/CXF-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8997: -- Affects Version/s: 3.6.3 > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java > > > Key: CXF-8997 > URL: https://issues.apache.org/jira/browse/CXF-8997 > Project: CXF > Issue Type: Test > Components: STS >Affects Versions: 3.6.3, 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Major > Fix For: 4.0.5 > > > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java. > Current builds of CXF 4.0.x on IBM Java will fail the AbstractSTSTokenTest > and TransportBindingTests due to their use of TLSv1. Note: IBM JDKs disable > TLSv1 by default since around Java 8 > (https://community.ibm.com/community/user/wasdevops/blogs/hiroko-takamiya1/2021/06/19/ibm-java-80630-disables-tlsv1-tlsv11-by-default-ho). > Removing the test case IBM control flag allows the default TLS to pass the > tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8998) cxf-codegen-plugin - debug output velocity
[
https://issues.apache.org/jira/browse/CXF-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833655#comment-17833655
]
Freeman Yue Fang commented on CXF-8998:
---
Hi [~khmarbaise],
I just quick tested samples/wsdl_first shipped with CXF 4.0.4 kit, but I can't
see the DEBUG org.apache.velocity output there.
Any chance you can append a reproducer project so that we can take a closer
look?
Thanks!
Freeman
> cxf-codegen-plugin - debug output velocity
> --
>
> Key: CXF-8998
> URL: https://issues.apache.org/jira/browse/CXF-8998
> Project: CXF
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 4.0.4
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently we are using {{cxf-codegen-plugin}}, which produces allways
> debugging output of velocity, on the console
> {code}
> 15:59:45 [INFO]
> 15:59:45 [INFO] --- cxf-codegen:4.0.4:wsdl2java (default) @ wsdls ---
> 15:59:45 [INFO] Running code generation in fork mode...
> 15:59:45 [INFO] bin/java
> 15:59:45 [INFO] Building jar: /tmp/cxf-tmp-7/cxf-codegen.jar
> 15:59:45 [WARNING] Picked up JAVA_TOOL_OPTIONS: .
> 15:59:46 [INFO] 15:59:46.356 [main] DEBUG org.apache.velocity --
> Initializing Velocity, Calling init()...
> 15:59:46 [INFO] 15:59:46.360 [main] DEBUG org.apache.velocity -- Starting
> Apache Velocity v2.3
> 15:59:46 [INFO] 15:59:46.362 [main] DEBUG org.apache.velocity -- Default
> Properties resource: org/apache/velocity/runtime/defaults/velocity.properties
> 15:59:53 [INFO]
> {code}
> Is there an easy way to suppress the debug output for the execution of the
> plugin?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown
[
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833604#comment-17833604
]
Andriy Redko commented on CXF-8987:
---
Thanks a lot for confirming, [~carnevalegiacomo] , will be looking into it
shortly.
> Java 21 - HttpClientHTTPConduit thread locked during shutdown
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Priority: Blocker
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
> *- locked <0x00061cd2ab80> (a
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
> *at
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
> *at
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
> *at
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
> *at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>
> java.net.HttpClient.close
>
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8998) cxf-codegen-plugin - debug output velocity
Karl Heinz Marbaise created CXF-8998:
Summary: cxf-codegen-plugin - debug output velocity
Key: CXF-8998
URL: https://issues.apache.org/jira/browse/CXF-8998
Project: CXF
Issue Type: Improvement
Components: Configuration
Affects Versions: 4.0.4
Reporter: Karl Heinz Marbaise
Currently we are using {{cxf-codegen-plugin}}, which produces allways debugging
output of velocity, on the console
{code}
15:59:45 [INFO]
15:59:45 [INFO] --- cxf-codegen:4.0.4:wsdl2java (default) @ wsdls ---
15:59:45 [INFO] Running code generation in fork mode...
15:59:45 [INFO] bin/java
15:59:45 [INFO] Building jar: /tmp/cxf-tmp-7/cxf-codegen.jar
15:59:45 [WARNING] Picked up JAVA_TOOL_OPTIONS: .
15:59:46 [INFO] 15:59:46.356 [main] DEBUG org.apache.velocity -- Initializing
Velocity, Calling init()...
15:59:46 [INFO] 15:59:46.360 [main] DEBUG org.apache.velocity -- Starting
Apache Velocity v2.3
15:59:46 [INFO] 15:59:46.362 [main] DEBUG org.apache.velocity -- Default
Properties resource: org/apache/velocity/runtime/defaults/velocity.properties
15:59:53 [INFO]
{code}
Is there an easy way to suppress the debug output for the execution of the
plugin?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8997) AbstractSTSTokenTest and TransportBindingTests no longer need to set https protocol to TLSv1 on IBM Java
[ https://issues.apache.org/jira/browse/CXF-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie Mark Goodyear updated CXF-8997: - Flags: Patch > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java > > > Key: CXF-8997 > URL: https://issues.apache.org/jira/browse/CXF-8997 > Project: CXF > Issue Type: Test > Components: STS >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Major > Fix For: 4.0.5 > > > AbstractSTSTokenTest and TransportBindingTests no longer need to set https > protocol to TLSv1 on IBM Java. > Current builds of CXF 4.0.x on IBM Java will fail the AbstractSTSTokenTest > and TransportBindingTests due to their use of TLSv1. Note: IBM JDKs disable > TLSv1 by default since around Java 8 > (https://community.ibm.com/community/user/wasdevops/blogs/hiroko-takamiya1/2021/06/19/ibm-java-80630-disables-tlsv1-tlsv11-by-default-ho). > Removing the test case IBM control flag allows the default TLS to pass the > tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8997) AbstractSTSTokenTest and TransportBindingTests no longer need to set https protocol to TLSv1 on IBM Java
Jamie Mark Goodyear created CXF-8997: Summary: AbstractSTSTokenTest and TransportBindingTests no longer need to set https protocol to TLSv1 on IBM Java Key: CXF-8997 URL: https://issues.apache.org/jira/browse/CXF-8997 Project: CXF Issue Type: Test Components: STS Affects Versions: 4.0.4 Reporter: Jamie Mark Goodyear Fix For: 4.0.5 AbstractSTSTokenTest and TransportBindingTests no longer need to set https protocol to TLSv1 on IBM Java. Current builds of CXF 4.0.x on IBM Java will fail the AbstractSTSTokenTest and TransportBindingTests due to their use of TLSv1. Note: IBM JDKs disable TLSv1 by default since around Java 8 (https://community.ibm.com/community/user/wasdevops/blogs/hiroko-takamiya1/2021/06/19/ibm-java-80630-disables-tlsv1-tlsv11-by-default-ho). Removing the test case IBM control flag allows the default TLS to pass the tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown
[
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833499#comment-17833499
]
Giacomo Carnevale commented on CXF-8987:
Hi
same problem with OpenJdk 22
openjdk version "22" 2024-03-19
OpenJDK Runtime Environment (build 22+36-2370)
OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)
|*Java Stack*|at java.lang.Object.wait0(java.base@22/Native Method)
- waiting on [no object reference available]
at java.lang.Object.wait(java.base@22/Object.java:375)
at java.lang.Thread.join(java.base@22/Thread.java:2039)
- locked [0x000618372e08] (a
jdk.internal.net.http.HttpClientImpl$SelectorManager)
at java.lang.Thread.join(java.base@22/Thread.java:2167)
at
jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@22/HttpClientImpl.java:632)
at java.net.http.HttpClient.close(java.net.http@22/HttpClient.java:900)
at
jdk.internal.net.http.HttpClientFacade.close(java.net.http@22/HttpClientFacade.java:192)
at
org.apache.cxf.transport.http.HttpClientHTTPConduit.close(HttpClientHTTPConduit.java:125)
at
org.apache.cxf.endpoint.AbstractConduitSelector.close(AbstractConduitSelector.java:77)
at org.apache.cxf.endpoint.ClientImpl.destroy(ClientImpl.java:177)
at org.apache.camel.component.cxf.jaxws.CxfProducer.doStop(CxfProducer.java:93)
at org.apache.camel.support.service.BaseService.stop(BaseService.java:154)|
My workaround is to set system property
org.apache.cxf.transport.http.forceURLConnection=true
> Java 21 - HttpClientHTTPConduit thread locked during shutdown
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Priority: Blocker
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
> *- locked <0x00061cd2ab80> (a
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
> *at
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
> *at
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
> *at
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
> *at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>
> java.net.HttpClient.close
>
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8996) JAXRS Bean introspection utility Beanspector relies on Class.getMethods natural order
[
https://issues.apache.org/jira/browse/CXF-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie Mark Goodyear updated CXF-8996:
-
Flags: Patch
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order
> -
>
> Key: CXF-8996
> URL: https://issues.apache.org/jira/browse/CXF-8996
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.0.5
>
>
> JAXRS Bean introspection utility Beanspector relies on Class.getMethods
> natural order.
> For most JVMs the Beanspector Tests will pass, however IBM Java does not
> return methods in the same ordering. Note: Class.getMethods does not provide
> a prescribed ordering of methods.
> When CXF 4.0.x main branch is built, we'll observe:
> {{Apache CXF JAX-RS Extensions: Search fails.}}
> {{{}[ERROR] Failures:{}}}{{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans{}}}{{{}[ERROR]
> Run 1: BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 2:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 3:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}{{{}[ERROR] Run 4:
> BeanspectorTest.testMismatchedOverriddenBeans Expected exception:
> java.lang.IllegalArgumentException{}}}
> {{{}[ERROR]
> org.apache.cxf.jaxrs.ext.search.BeanspectorTest.testMismatchedOverriddenBeans
> - Time elapsed: 0.001 s <<< FAILURE!{}}}{{{}java.lang.AssertionError:
> Expected exception: java.lang.IllegalArgumentException{}}}
> We can improve this behaviour by detecting when IBM Java is in use, and
> having IBM process declared methods first, then process remaining methods.
> This will make IBM behave more like other JVMs.
> I will provide a PR with the change in place. Currently testing on a variety
> of platforms/JVMs to ensure tests pass.
> {{//Class.getMethods does not provide an ordering.}}
> {{//IBM Java tends to have a different ordering than other JVMs, so process
> declared methods first.}}
> {{//Process remaining methods after to not miss getter/setters.}}
> {{if ("IBM Corporation".equals(System.getProperty("java.vendor"))) {}}
> {{processMethods(tclass.getDeclaredMethods());}}
> {{}}}
> {{processMethods(tclass.getMethods());}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
