oscerd commented on code in PR #27433:
URL: https://github.com/apache/camel/pull/27433#discussion_r4195062696
##########
core/camel-core/src/test/java/org/apache/camel/support/jsse/SSLContextParametersTest.java:
##########
@@ -1069,20 +1070,17 @@ public void testSignatureSchemesFilter_postJDK26()
throws Exception {
int defaultSignatureSchemeNumber =
getSignatureSchemes(engine.getSSLParameters()).length;
- // a filter cannot be applied as there are no default schemes to
filter, so the defaults are kept (null)
- // instead of an empty list (which would fail every handshake)
+ // empty filter - no includes means no schemes match (empty array)
Review Comment:
**JDK 26, and the behaviour this pins**
Two questions, since this method is `@EnabledForJreRange(min = JRE.JAVA_26)`
and CI only builds with 17 and 25, so it never runs there:
- **JDK 26:** `BaseSSLContextParameters` returns `null` (keeps the defaults,
with a WARN) when the JVM does not tell its default signature schemes, and the
previous assertions expected exactly that. If JDK 26 GA still takes that
branch, these new assertions fail there, because AssertJ's `isEmpty()` rejects
`null`. If 26 and 27 differ, gating the expectation on whether the defaults are
provided, or splitting the method by JRE range, would keep it green on both.
- **Behaviour pinned here:** with defaults available, an empty
`FilterParameters` now yields zero signature schemes, which makes every
handshake fail. The null branch deliberately avoids that ("configuring an empty
list would fail every handshake"). Is an empty result the intended
`FilterParameters` semantics here, consistent with cipher suites? Or should the
production code also WARN, or keep the defaults, when the filter leaves nothing?
##########
core/camel-core/src/test/java/org/apache/camel/support/jsse/SSLContextParametersTest.java:
##########
@@ -1069,20 +1070,17 @@ public void testSignatureSchemesFilter_postJDK26()
throws Exception {
int defaultSignatureSchemeNumber =
getSignatureSchemes(engine.getSSLParameters()).length;
- // a filter cannot be applied as there are no default schemes to
filter, so the defaults are kept (null)
- // instead of an empty list (which would fail every handshake)
+ // empty filter - no includes means no schemes match (empty array)
FilterParameters filter = new FilterParameters();
- filter.getInclude().add(".*");
scp.setSignatureSchemesFilter(filter);
context = scp.createSSLContext(null);
engine = context.createSSLEngine();
socket = (SSLSocket) context.getSocketFactory().createSocket();
serverSocket = (SSLServerSocket)
context.getServerSocketFactory().createServerSocket();
- assertNull(getSignatureSchemes(engine.getSSLParameters()));
- assertNull(getSignatureSchemes(socket.getSSLParameters()));
- assertNull(getSignatureSchemes(serverSocket.getSSLParameters()));
- filter.getInclude().clear();
+ assertThat(getSignatureSchemes(engine.getSSLParameters())).isEmpty();
+ assertThat(getSignatureSchemes(socket.getSSLParameters())).isEmpty();
+
assertThat(getSignatureSchemes(serverSocket.getSSLParameters())).isEmpty();
Review Comment:
**Keep the JUnit assertion style of this method**
This method otherwise uses JUnit assertions (and the class imports
`org.junit.jupiter.api.Assertions.*`), and CLAUDE.md asks not to mix AssertJ
and JUnit in the same test method and to follow the module's predominant style.
Keeping JUnit here (and dropping the new `assertThat` import at line 39):
```suggestion
assertEquals(0,
getSignatureSchemes(engine.getSSLParameters()).length);
assertEquals(0,
getSignatureSchemes(socket.getSSLParameters()).length);
assertEquals(0,
getSignatureSchemes(serverSocket.getSSLParameters()).length);
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
