apupier opened a new pull request, #28733:
URL: https://github.com/apache/camel/pull/28733
Missing fix from the previous commit (7eab79adfeb9): the same shared-static
CXFTestSupport.getSslPort() / CXFTestSupport.sslPort system-property collision
that was fixed in camel-cxf-rest and camel-cxf-soap was not addressed for the
three SSL producer tests in camel-cxf-spring-rest.
Root cause
----------
CXFTestSupport.SSL_PORT is a single static AvailablePortFinder.Port
allocated once at JVM class-load time and exposed through
CXFTestSupport.getSslPort(). All three SSL test classes stored it in a static
int field:
private static int port1 = CXFTestSupport.getSslPort();
When Maven Surefire ran these test classes in concurrent Surefire forks
(enabled by reuseForks=false + forkCount in the parent camel-cxf pom), every
fork loaded CXFTestSupport and resolved SSL_PORT to the same integer. All
three classes then tried to start an Undertow HTTPS listener on that port
simultaneously, causing:
java.net.BindException: Address already in use
Could not start Undertow server on port 45,423
Affected classes
----------------
- CxfRsSslProducerTest
- CxfRsSslAsyncProducerTest
- CxfRsGlobalSslProducerTest
Fix
---
Replace CXFTestSupport.getSslPort() with a per-class @RegisterExtension
static final AvailablePortFinder.Port SSL_PORT so each test class reserves its
own unique SSL port from the OS.
Because the three Spring XML configs reference ${CXFTestSupport.sslPort} via
Spring PropertyPlaceholderConfigurer, each class also sets that system property
in a @BeforeAll method that runs before CamelSpringTestSupport initialises the
ApplicationContext (which happens in @BeforeEach):
@BeforeAll
static void reserveSslPort() {
System.setProperty("CXFTestSupport.sslPort", SSL_PORT.toString());
}
Co-authored-by: IBM Bob 2.2.1
In another iteration, I think we should get rid of CXfTestSupport and use
distinct port for every test classes to reduce potential port collisions
# Description
<!--
- Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
-->
# Target
- [ ] I checked that the commit is targeting the correct branch (Camel 4
uses the `main` branch)
# Tracking
- [ ] If this is a large change, bug fix, or code improvement, I checked
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for
the change (usually before you start working on it).
<!--
# *Note*: trivial changes like, typos, minor documentation fixes and other
small items do not require a JIRA issue. In this case your pull request should
address just this issue, without pulling in other changes.
-->
# Apache Camel coding standards and style
- [ ] I checked that each commit in the pull request has a meaningful
subject line and body.
<!--
If you're unsure, you can format the pull request title like `[CAMEL-XXX]
Fixes bug in camel-file component`, where you replace `CAMEL-XXX` with the
appropriate JIRA issue.
-->
- [ ] I have run `mvn clean install -DskipTests` locally from root folder
and I have committed all auto-generated changes.
<!--
You can run the aforementioned command in your module so that the build
auto-formats your code. This will also be verified as part of the checks and
your PR may be rejected if if there are uncommited changes after running `mvn
clean install -DskipTests`.
You can learn more about the contribution guidelines at
https://github.com/apache/camel/blob/main/CONTRIBUTING.md
-->
# AI-assisted contributions
- [ ] If this PR includes AI-generated code, commits have proper
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR
description identifies the AI tool used.
--
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]
