[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=17769298#comment-17769298
]
Laurent SCHOELENS commented on CXF-8932:
OK so not a real regression
More a fix with unexpected issue
Thanks for the reply, and waiting to test new 4.0.4 release when out
> [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] [Comment Edited] (CXF-8932) [WSDL2JAVA] Not working on JDK11
[
https://issues.apache.org/jira/browse/CXF-8932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769296#comment-17769296
]
Andriy Redko edited comment on CXF-8932 at 9/26/23 5:36 PM:
[~laurent.schoelens] thanks for continue to dig in, 4.0.2 we had an issue that
plugins were using the Spring Framework 5.3.x (but should have been using 6.0.x
instead):
{noformat}
[INFO] org.springframework:spring-core:jar:5.3.24
[INFO] org.springframework:spring-jcl:jar:5.3.24
[INFO] org.springframework:spring-beans:jar:5.3.24
[INFO] org.springframework:spring-context:jar:5.3.24
[INFO] org.springframework:spring-aop:jar:5.3.24
[INFO] org.springframework:spring-expression:jar:5.3.24
{noformat}
It was fixed.
was (Author: reta):
[~laurent.schoelens] thanks for continue to dig in, 4.0.2 we had an issue that
plugins were using the Spring Framework 5.3.x (bud should have been using 6.0.x
instead):
{noformat}
[INFO] org.springframework:spring-core:jar:5.3.24
[INFO] org.springframework:spring-jcl:jar:5.3.24
[INFO] org.springframework:spring-beans:jar:5.3.24
[INFO] org.springframework:spring-context:jar:5.3.24
[INFO] org.springframework:spring-aop:jar:5.3.24
[INFO] org.springframework:spring-expression:jar:5.3.24
{noformat}
It was fixed.
> [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] [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=17769296#comment-17769296
]
Andriy Redko commented on CXF-8932:
---
[~laurent.schoelens] thanks for continue to dig, in 4.0.2 we had an issue that
plugins were using the Spring Framework 5.3.x (bud should have been using 6.0.x
instead):
{noformat}
[INFO] org.springframework:spring-core:jar:5.3.24
[INFO] org.springframework:spring-jcl:jar:5.3.24
[INFO] org.springframework:spring-beans:jar:5.3.24
[INFO] org.springframework:spring-context:jar:5.3.24
[INFO] org.springframework:spring-aop:jar:5.3.24
[INFO] org.springframework:spring-expression:jar:5.3.24
{noformat}
It was fixed.
> [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] [Comment Edited] (CXF-8932) [WSDL2JAVA] Not working on JDK11
[
https://issues.apache.org/jira/browse/CXF-8932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769296#comment-17769296
]
Andriy Redko edited comment on CXF-8932 at 9/26/23 5:35 PM:
[~laurent.schoelens] thanks for continue to dig in, 4.0.2 we had an issue that
plugins were using the Spring Framework 5.3.x (bud should have been using 6.0.x
instead):
{noformat}
[INFO] org.springframework:spring-core:jar:5.3.24
[INFO] org.springframework:spring-jcl:jar:5.3.24
[INFO] org.springframework:spring-beans:jar:5.3.24
[INFO] org.springframework:spring-context:jar:5.3.24
[INFO] org.springframework:spring-aop:jar:5.3.24
[INFO] org.springframework:spring-expression:jar:5.3.24
{noformat}
It was fixed.
was (Author: reta):
[~laurent.schoelens] thanks for continue to dig, in 4.0.2 we had an issue that
plugins were using the Spring Framework 5.3.x (bud should have been using 6.0.x
instead):
{noformat}
[INFO] org.springframework:spring-core:jar:5.3.24
[INFO] org.springframework:spring-jcl:jar:5.3.24
[INFO] org.springframework:spring-beans:jar:5.3.24
[INFO] org.springframework:spring-context:jar:5.3.24
[INFO] org.springframework:spring-aop:jar:5.3.24
[INFO] org.springframework:spring-expression:jar:5.3.24
{noformat}
It was fixed.
> [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-8936) Fix h2 protocol negotiation in Jetty Transport
[
https://issues.apache.org/jira/browse/CXF-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Huw Ayling-Miller updated CXF-8936:
---
Description:
h1. Summary
I have been trying to update one of our apps using the Jetty backend to use
http2. While doing this I've noticed that the protocol negotiation is in the
wrong order which results in http/1.1 always being preferred where the client
includes this in the ALPN handshake. This means that both browsers and cURL
will never successfully negotiate h2/http2.
---
h1. The problem
The issue can be shown using curl.
{{curl -ikv https://localhost:9000}}
I've attached the full output of this command when running curl against the CXF
sample {{jax_rs_basic_http2_jetty}}.
The important lines are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted http/1.1
{code}
Compare this with the attached curl output from the CXF sample
{{jax_rs_basic_http2_netty}}.
The important lines here are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted h2
{code}
---
h1. The solution
The ALPN takes place within {{ALPNServerConnection}}, which is part of the
{{jetty-alpn-server}} module.
{code:java}
// RFC 7301 states that the server picks the protocol
// that it prefers that is also supported by the client.
for (String serverProtocol : serverProtocols)
{
if (clientProtocols.contains(serverProtocol))
{
ConnectionFactory factory =
getConnector().getConnectionFactory(serverProtocol);
if (factory instanceof CipherDiscriminator &&
!((CipherDiscriminator)factory).isAcceptable(serverProtocol, tlsProtocol,
tlsCipher))
{
if (LOG.isDebugEnabled())
LOG.debug("Protocol {} not acceptable to {} for {}/{}
on {}", serverProtocol, factory, tlsProtocol, tlsCipher, getEndPoint());
continue;
}
negotiated = serverProtocol;
break;
}
}
{code}
As the code states, the server is responsible for picking the protocol and
Jetty picks the first match in the server's list. From the log output of the
same app the first in the list is http/1.1
{code}
INFO: Started ServerConnector@11eadcba\{ssl, (http/1.1, ssl, alpn,
h2)}{0.0.0.0:9000}}
{code}
Therefore the solution is to ensure that when h2 is enabled inside
{{JettyHTTPServerEngine}} -> {{createConnectorJetty}}, the
HTTP2ServerConnectionFactory should always be added at the start of the list.
With this change, curl then successfully negotiates with h2.
was:
h1. Summary
I have been trying to update one of our apps using the Jetty backend to use
http2. While doing this I've noticed that the protocol negotiation is in the
wrong order which results in http/1.1 always being preferred where the client
includes this in the ALPN handshake. This means that both browsers and cURL
will never successfully negotiate h2/http2.
---
h1. The problem
The issue can be shown using curl.
{{curl -ikv https://localhost:9000}}
I've attached the full output of this command when running curl against the CXF
sample {{jax_rs_basic_http2_jetty}}.
The important lines are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted http/1.1
{code}
Compare this with the attached curl output from the CXF sample
{{jax_rs_basic_http2_netty}}.
The important lines here are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted h2
{code}
---
h1. The solution
The ALPN protocol selection takes place within {{ALPNServerConnection}}, which
is part of the {{jetty-alpn-server}} module.
{code:java}
// RFC 7301 states that the server picks the protocol
// that it prefers that is also supported by the client.
for (String serverProtocol : serverProtocols)
{
if (clientProtocols.contains(serverProtocol))
{
ConnectionFactory factory =
getConnector().getConnectionFactory(serverProtocol);
if (factory instanceof CipherDiscriminator &&
!((CipherDiscriminator)factory).isAcceptable(serverProtocol, tlsProtocol,
tlsCipher))
{
if (LOG.isDebugEnabled())
LOG.debug("Protocol {} not acceptable to {} for {}/{}
on {}", serverProtocol, factory, tlsProtocol, tlsCipher, getEndPoint());
continue;
}
negotiated = serverProtocol;
break;
}
}
{code}
As the code states, the server is responsible for picking the protocol and
Jetty picks the first match in the server's list. From the log output of the
same app the first in the list is http/1.1
{code}
INFO: Started ServerConnector@11eadcba\{ssl, (http/1.1, ssl, alpn,
h2)}{0.0.0.0:9000}}
{code}
Therefore the solution is to ensure that when h2 is enabled inside
[jira] [Updated] (CXF-8936) Fix h2 protocol negotiation in Jetty Transport
[
https://issues.apache.org/jira/browse/CXF-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Huw Ayling-Miller updated CXF-8936:
---
Description:
h1. Summary
I have been trying to update one of our apps using the Jetty backend to use
http2. While doing this I've noticed that the protocol negotiation is in the
wrong order which results in http/1.1 always being preferred where the client
includes this in the ALPN handshake. This means that both browsers and cURL
will never successfully negotiate h2/http2.
---
h1. The problem
The issue can be shown using curl.
{{curl -ikv https://localhost:9000}}
I've attached the full output of this command when running curl against the CXF
sample {{jax_rs_basic_http2_jetty}}.
The important lines are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted http/1.1
{code}
Compare this with the attached curl output from the CXF sample
{{jax_rs_basic_http2_netty}}.
The important lines here are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted h2
{code}
---
h1. The solution
The ALPN protocol selection takes place within {{ALPNServerConnection}}, which
is part of the {{jetty-alpn-server}} module.
{code:java}
// RFC 7301 states that the server picks the protocol
// that it prefers that is also supported by the client.
for (String serverProtocol : serverProtocols)
{
if (clientProtocols.contains(serverProtocol))
{
ConnectionFactory factory =
getConnector().getConnectionFactory(serverProtocol);
if (factory instanceof CipherDiscriminator &&
!((CipherDiscriminator)factory).isAcceptable(serverProtocol, tlsProtocol,
tlsCipher))
{
if (LOG.isDebugEnabled())
LOG.debug("Protocol {} not acceptable to {} for {}/{}
on {}", serverProtocol, factory, tlsProtocol, tlsCipher, getEndPoint());
continue;
}
negotiated = serverProtocol;
break;
}
}
{code}
As the code states, the server is responsible for picking the protocol and
Jetty picks the first match in the server's list. From the log output of the
same app the first in the list is http/1.1
{code}
INFO: Started ServerConnector@11eadcba\{ssl, (http/1.1, ssl, alpn,
h2)}{0.0.0.0:9000}}
{code}
Therefore the solution is to ensure that when h2 is enabled inside
{{JettyHTTPServerEngine}} -> {{createConnectorJetty}}, the
HTTP2ServerConnectionFactory should always be added at the start of the list.
With this change, curl then successfully negotiates with h2.
was:
h1. Summary
I have been trying to update one of our apps using the Jetty backend to use
http2. While doing this I've noticed that the protocol negotiation is in the
wrong order which results in http/1.1 always being preferred where the client
includes this in the ALPN handshake. This means that both browsers and cURL
will never successfully negotiate h2/http2.
---
h1. The problem
The issue can be shown using curl.
{{curl -ikv https://localhost:9000}}
I've attached the full output of this command when running curl against the CXF
sample `jax_rs_basic_http2_jetty`.
The important lines are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted http/1.1
{code}
Compare this with the attached curl output from the CXF sample
{{jax_rs_basic_http2_netty}}.
The important lines here are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted h2
{code}
---
h1. The solution
The ALPN protocol selection takes place within {{ALPNServerConnection}}, which
is part of the {{jetty-alpn-server}} module.
{code:java}
// RFC 7301 states that the server picks the protocol
// that it prefers that is also supported by the client.
for (String serverProtocol : serverProtocols)
{
if (clientProtocols.contains(serverProtocol))
{
ConnectionFactory factory =
getConnector().getConnectionFactory(serverProtocol);
if (factory instanceof CipherDiscriminator &&
!((CipherDiscriminator)factory).isAcceptable(serverProtocol, tlsProtocol,
tlsCipher))
{
if (LOG.isDebugEnabled())
LOG.debug("Protocol {} not acceptable to {} for {}/{}
on {}", serverProtocol, factory, tlsProtocol, tlsCipher, getEndPoint());
continue;
}
negotiated = serverProtocol;
break;
}
}
{code}
As the code states, the server is responsible for picking the protocol and
Jetty picks the first match in the server's list. From the log output of the
same app the first in the list is http/1.1
{code}
INFO: Started ServerConnector@11eadcba\{ssl, (http/1.1, ssl, alpn,
h2)}{0.0.0.0:9000}}
{code}
Therefore the solution is to ensure that when h2 is enabled inside
[jira] [Commented] (CXF-8936) Fix h2 protocol negotiation in Jetty Transport
[
https://issues.apache.org/jira/browse/CXF-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769286#comment-17769286
]
Huw Ayling-Miller commented on CXF-8936:
PR - https://github.com/apache/cxf/pull/1454
> Fix h2 protocol negotiation in Jetty Transport
> --
>
> Key: CXF-8936
> URL: https://issues.apache.org/jira/browse/CXF-8936
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
> Environment: CXF latest and CXF 4.0.3 on Java 11 and 17 both show
> this issue.
>Reporter: Huw Ayling-Miller
>Priority: Minor
> Labels: Jetty
> Attachments: output-jetty-original.txt, output-netty.txt
>
>
> h1. Summary
> I have been trying to update one of our apps using the Jetty backend to use
> http2. While doing this I've noticed that the protocol negotiation is in the
> wrong order which results in http/1.1 always being preferred where the client
> includes this in the ALPN handshake. This means that both browsers and cURL
> will never successfully negotiate h2/http2.
> ---
> h1. The problem
> The issue can be shown using curl.
> {{curl -ikv https://localhost:9000}}
> I've attached the full output of this command when running curl against the
> CXF sample `jax_rs_basic_http2_jetty`.
> The important lines are:
> {code}
> * ALPN: offers h2,http/1.1
> * ALPN: server accepted http/1.1
> {code}
> Compare this with the attached curl output from the CXF sample
> {{jax_rs_basic_http2_netty}}.
> The important lines here are:
> {code}
> * ALPN: offers h2,http/1.1
> * ALPN: server accepted h2
> {code}
> ---
> h1. The solution
> The ALPN protocol selection takes place within {{ALPNServerConnection}},
> which is part of the {{jetty-alpn-server}} module.
> {code:java}
> // RFC 7301 states that the server picks the protocol
> // that it prefers that is also supported by the client.
> for (String serverProtocol : serverProtocols)
> {
> if (clientProtocols.contains(serverProtocol))
> {
> ConnectionFactory factory =
> getConnector().getConnectionFactory(serverProtocol);
> if (factory instanceof CipherDiscriminator &&
> !((CipherDiscriminator)factory).isAcceptable(serverProtocol, tlsProtocol,
> tlsCipher))
> {
> if (LOG.isDebugEnabled())
> LOG.debug("Protocol {} not acceptable to {} for {}/{}
> on {}", serverProtocol, factory, tlsProtocol, tlsCipher, getEndPoint());
> continue;
> }
> negotiated = serverProtocol;
> break;
> }
> }
> {code}
> As the code states, the server is responsible for picking the protocol and
> Jetty picks the first match in the server's list. From the log output of the
> same app the first in the list is http/1.1
> {code}
> INFO: Started ServerConnector@11eadcba\{ssl, (http/1.1, ssl, alpn,
> h2)}{0.0.0.0:9000}}
> {code}
> Therefore the solution is to ensure that when h2 is enabled inside
> {{JettyHTTPServerEngine}} -> {{createConnectorJetty}}, the
> HTTP2ServerConnectionFactory should always be added at the start of the list.
> With this change, curl then successfully negotiates with h2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8936) Fix h2 protocol negotiation in Jetty Transport
Huw Ayling-Miller created CXF-8936:
--
Summary: Fix h2 protocol negotiation in Jetty Transport
Key: CXF-8936
URL: https://issues.apache.org/jira/browse/CXF-8936
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 4.0.3
Environment: CXF latest and CXF 4.0.3 on Java 11 and 17 both show this
issue.
Reporter: Huw Ayling-Miller
Attachments: output-jetty-original.txt, output-netty.txt
h1. Summary
I have been trying to update one of our apps using the Jetty backend to use
http2. While doing this I've noticed that the protocol negotiation is in the
wrong order which results in http/1.1 always being preferred where the client
includes this in the ALPN handshake. This means that both browsers and cURL
will never successfully negotiate h2/http2.
---
h1. The problem
The issue can be shown using curl.
{{curl -ikv https://localhost:9000}}
I've attached the full output of this command when running curl against the CXF
sample `jax_rs_basic_http2_jetty`.
The important lines are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted http/1.1
{code}
Compare this with the attached curl output from the CXF sample
{{jax_rs_basic_http2_netty}}.
The important lines here are:
{code}
* ALPN: offers h2,http/1.1
* ALPN: server accepted h2
{code}
---
h1. The solution
The ALPN protocol selection takes place within {{ALPNServerConnection}}, which
is part of the {{jetty-alpn-server}} module.
{code:java}
// RFC 7301 states that the server picks the protocol
// that it prefers that is also supported by the client.
for (String serverProtocol : serverProtocols)
{
if (clientProtocols.contains(serverProtocol))
{
ConnectionFactory factory =
getConnector().getConnectionFactory(serverProtocol);
if (factory instanceof CipherDiscriminator &&
!((CipherDiscriminator)factory).isAcceptable(serverProtocol, tlsProtocol,
tlsCipher))
{
if (LOG.isDebugEnabled())
LOG.debug("Protocol {} not acceptable to {} for {}/{}
on {}", serverProtocol, factory, tlsProtocol, tlsCipher, getEndPoint());
continue;
}
negotiated = serverProtocol;
break;
}
}
{code}
As the code states, the server is responsible for picking the protocol and
Jetty picks the first match in the server's list. From the log output of the
same app the first in the list is http/1.1
{code}
INFO: Started ServerConnector@11eadcba\{ssl, (http/1.1, ssl, alpn,
h2)}{0.0.0.0:9000}}
{code}
Therefore the solution is to ensure that when h2 is enabled inside
{{JettyHTTPServerEngine}} -> {{createConnectorJetty}}, the
HTTP2ServerConnectionFactory should always be added at the start of the list.
With this change, curl then successfully negotiates with h2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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=17769046#comment-17769046
]
Laurent SCHOELENS commented on CXF-8932:
[~reta] sorry to reping, but found out that 4.0.2 works well on jdk11, so it
seems more a regression in 4.0.2-4.0.3 changelog
> [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)
