Bump the jetty group across 1 directory with 7 updates

[dependabot]

Bumps the jetty group with 7 updates in the / directory:

Package	From	To
org.eclipse.jetty:jetty-server	12.0.35	12.1.9
org.eclipse.jetty:jetty-xml	12.0.35	12.1.9
org.eclipse.jetty:jetty-util	12.0.35	12.1.9
org.eclipse.jetty:jetty-jmx	12.0.35	12.1.9
org.eclipse.jetty:jetty-security	12.0.35	12.1.9
org.eclipse.jetty:jetty-http	12.0.35	12.1.9
org.eclipse.jetty:jetty-deploy	12.0.35	12.1.9

Updates org.eclipse.jetty:jetty-server from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-xml from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-util from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-jmx from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-security from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-http from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-deploy from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-xml from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-util from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-jmx from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-security from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-http from 12.0.35 to 12.1.9

Updates org.eclipse.jetty:jetty-deploy from 12.0.35 to 12.1.9

[dizzzz]

Windows fail

[dizzzz]

according to copilot:

I'll help you find a solution for the failing job. Let me start by retrieving the logs for that job.Now let me get the test file to understand what's failing:## Solution for Job 75920500154

The job is failing due to test failures in the exist-file module, specifically in the RestBinariesTest class. There are 6 failing tests out of 63 total tests.

Root Causes

1. REST API Unavailability - Tests RestBinariesTest.readAndStreamBinaryRaw, readAndStreamBinarySax, readBinary, and readAndWriteBinary fail with "Unable to store binary file" and "Unable to delete collection" errors. This indicates the REST server isn't properly initialized or is becoming unavailable during test execution.

2. Remote Service Unavailable - Tests XmldbBinariesTest.readBinary[remote] and readAndWriteBinary[remote] fail with "HTTP server returned unexpected status: Service Unavailable", suggesting the embedded web server is timing out or crashing during the test suite.

Recommended Fixes

Option 1: Add Retry Logic with Exponential Backoff

Modify RestBinariesTest.java to add resilience to HTTP requests:

private HttpResponse executeWithRetry(Request request, int maxRetries) throws IOException {
    int retries = 0;
    IOException lastException = null;
    
    while (retries < maxRetries) {
        try {
            return executor.execute(request).returnResponse();
        } catch (IOException e) {
            lastException = e;
            retries++;
            if (retries < maxRetries) {
                try {
                    Thread.sleep((long) Math.pow(2, retries) * 100); // Exponential backoff
                } catch (InterruptedException ie) {
                    Thread.currentThread().interrupt();
                    throw new IOException("Interrupted during retry", ie);
                }
            }
        }
    }
    throw lastException;
}

@Override
protected void storeBinaryFile(final XmldbURI filePath, final byte[] content) throws Exception {
    final HttpResponse response = executeWithRetry(
        Request.Put(getRestUrl() + filePath.toString())
            .setHeader("Content-Type", "application/octet-stream")
            .bodyByteArray(content),
        3
    );

    if(response.getStatusLine().getStatusCode() != SC_CREATED) {
        throw new Exception("Unable to store binary file: " + filePath);
    }
}

Option 2: Increase Server Startup Timeout

The ExistWebServer may need more time to initialize. In the test class, increase timeouts:

@BeforeClass
public static void setupExecutor() {
    // Add connection and socket timeout configuration
    executor = Executor.newInstance()
            .auth(new HttpHost("localhost", existWebServer.getPort()), ADMIN_DB_USER, ADMIN_DB_PWD)
            .authPreemptive(new HttpHost("localhost", existWebServer.getPort()))
            .use(PoolingHttpClientConnectionManager.newInstance());
    
    // Wait for server to be ready
    waitForServerReady(10000); // 10 second timeout
}

private static void waitForServerReady(long timeoutMs) throws IOException {
    long startTime = System.currentTimeMillis();
    while (System.currentTimeMillis() - startTime < timeoutMs) {
        try {
            final HttpResponse response = executor.execute(
                Request.Head(getRestUrl() + "/db/")
            ).returnResponse();
            if (response.getStatusLine().getStatusCode() < 500) {
                return; // Server is ready
            }
        } catch (IOException e) {
            // Server not ready yet
        }
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new IOException("Interrupted waiting for server", e);
        }
    }
    throw new IOException("Server failed to become ready within timeout");
}

Option 3: Mark Tests as Flaky (Temporary)

If the above solutions don't work, mark problematic tests to retry on failure:

@Test
@Flaky(retries = 3)
public void readAndStreamBinaryRaw() throws IOException, JAXBException {
    // test code
}

Additional Notes

• The initial Maven metadata warnings about org.eclipse.emf:org.eclipse.emf.common suggest dependency resolution issues that could be contributing to server initialization problems. Ensure all dependencies are properly cached.
• Consider checking if the embedded web server is shutting down prematurely during parallel test execution.

[dizzzz]

It seems to be possible to reproduce on macOS:

[dizzzz]

a bit more is wrong; asking Junie:

Jetty 12 Multiple Embedded Servers — Workarounds

Jetty 12 introduced stricter lifecycle management and some global/static state that can conflict when multiple Server instances run in the same JVM. Here are the main approaches to work around this:

1. Serialize test execution (simplest fix)

Ensure only one ExistWebServer is running at a time by running tests sequentially. In Maven Surefire:

<configuration>
    <forkCount>1</forkCount>
    <reuseForks>false</reuseForks>
    <parallel>none</parallel>
</configuration>

Or annotate test classes with JUnit 5's @ResourceLock / JUnit 4's @FixMethodOrder to prevent concurrent startup.

2. Use a single shared server instance (recommended for unit tests)

Instead of each test class spinning up its own ExistWebServer, share one instance across the entire test suite using a JUnit @ClassRule or a JUnit 5 extension with @BeforeAll/@afterall at the suite level.

@ClassRule
public static final ExistWebServer server = new ExistWebServer(true, false, true, true);

This is the most robust approach — one server, one port, no conflicts.

3. Fork each test class into its own JVM process

Maven Surefire can fork a new JVM per test class, completely isolating Jetty instances:

<configuration>
    <forkCount>1</forkCount>
    <reuseForks>false</reuseForks>
</configuration>

With reuseForks=false, each test class gets a fresh JVM — no shared static state at all. The downside is slower test execution due to JVM startup overhead.

4. Isolate Jetty's ShutdownThread / global handlers

Jetty 12 registers a JVM shutdown hook (ShutdownThread) as a singleton. When a second Server starts, it may conflict. You can work around this by:

• Calling server.setStopAtShutdown(false) on each embedded Server instance and managing lifecycle manually.
• Checking if JettyStart exposes the underlying org.eclipse.jetty.server.Server — if so, disable the shutdown hook before starting a second instance.

5. Use different ThreadPool instances

Jetty 12 requires each Server to have its own QueuedThreadPool. If JettyStart reuses or shares a thread pool (e.g., via a static field), two servers will conflict. Ensure each JettyStart creates a fresh QueuedThreadPool:
Server server = new Server(new QueuedThreadPool());

6. Check for static/global Jetty state in JettyStart

Look at org.exist.jetty.JettyStart for:

• Static Server fields
• Static ShutdownThread registration
• Shared MBeanContainer or JMX registration (Jetty 12 MBeans use global MBeanServer — two servers registering the same MBean names will throw)
  If JMX is the culprit, disable it in the embedded test configuration:

<!-- In jetty.xml / test jetty config -->
<!-- Remove or comment out JMX configuration -->

Recommended approach for ExistWebServer
Given the current design, the best pragmatic fix is:

1. Short term: Add synchronized(ExistWebServer.class) around the entire before()/after() lifecycle (not just port selection) so servers start and stop sequentially — the second server only starts after the first has fully shut down.
2. Medium term: Refactor tests that need HTTP access to share a single @ClassRule ExistWebServer instance, avoiding the need for multiple concurrent servers entirely.

The synchronized block you already have around port selection in useRandomPort mode is a good start — extending it to cover the full server.run() + server.shutdown() lifecycle would prevent the overlap that Jetty 12 dislikes.