Fix CLDR locale adapter warnings during test security policy loading

[Copilot]

On CI runners with minimal JDK builds, every test JVM process emits one warning per java.net.URLPermission entry in the security policy file:

java.security.policy: error adding Permission, java.net.URLPermission:
    java.util.ServiceConfigurationError: Locale provider adapter "CLDR" cannot be instantiated.

URLPermission instantiation triggers locale service loading; when the CLDR adapter isn't available, policy loading fails silently for each of the 14 URLPermission entries (those permissions are dropped) and the warnings flood the log.

Change

• gradle/testing/defaults-tests.gradle: Add java.locale.providers=COMPAT,CLDR as a system property for all test JVMs. COMPAT is always available in any standard JDK and handles the locale lookup before CLDR is attempted, eliminating the instantiation failure. CLDR remains as a fallback for tests that rely on CLDR-formatted data.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• develocity.apache.org
  • Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -XX:ReservedCodeCacheSize=256m -XX:TieredStopAtLevel=1 -XX:+UseParallelGC -XX:ActiveProcessorCount=1 --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Create a pull request in epugh/solr (base branch main) to address recurring CI log warnings/errors:

• java.util.ServiceConfigurationError: Locale provider adapter "CLDR" cannot be instantiated.
• java.security.policy: error adding Permission, java.net.URLPermission:

Context:

• Seen in GitHub Actions run job logs: https://github.com/apache/solr/actions/runs/25254134941/job/74050919043
• Workflow involved upstream: .github/workflows/tests-via-crave.yml

Task requirements:

1. Locate the source of these warnings in the fork repository (Gradle config, test JVM args, security policy files, locale provider settings).
2. Implement a fix so the Gradle test task does not emit these warnings (or they are properly handled), without simply silencing stderr. Prefer correcting the underlying configuration.
   • Consider setting an explicit locale provider via JVM system property java.locale.providers for test JVMs if appropriate.
   • For the java.security.policy URLPermission warnings, locate the policy file / permission additions and correct the syntax/format or remove invalid entries.
3. Ensure ./gradlew test passes.
4. Update docs/comments if needed.

Deliverables:

• Code/config changes
• PR description explaining root cause and fix

Notes:

• Keep compatible with supported JDK versions.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The failing job is ultimately caused by test failures, not by the earlier locale/policy noise in the log.

What failed

From the job log (ref bf5d71c09ae80527c794c5f006ccc9637663d3dc):

• :solr:solrj:test (FAILURE) with failing test:
  • org.apache.solr.client.solrj.impl.LB2SolrClientTest.testTwoServers

The repeated
java.util.ServiceConfigurationError: Locale provider adapter "CLDR" cannot be instantiated
messages appear, but the job is marked failed specifically because of failing Gradle test tasks.

Root cause (most likely)

LB2SolrClientTest.testTwoServers() is timing-sensitive and relies on log-based coordination to detect that the “alive check” ran:

if (logListener.pollMessage(10, TimeUnit.SECONDS) == null) {
  fail("The alive check query was not logged within 10 seconds.");
}

(see startJettyAndWaitForAliveCheckQuery, lines 276–284 in solr/solrj/src/test/.../LB2SolrClientTest.java, ref bf5d71c09ae80527c794c5f006ccc9637663d3dc)

This is fragile because:

• the alive-check may happen later than 10s under load/CI variance,
• logging level/configuration/async logging can delay or suppress the message,
• the client’s scheduler timing is inherently nondeterministic.

So the test can fail even when functionality is correct.

Fix: make the test wait on behavior, not logs

Change startJettyAndWaitForAliveCheckQuery to verify recovery by retrying an actual query until it succeeds, instead of asserting a specific log line appears within 10 seconds.

Suggested patch (drop log dependency, use retry on query result)

In LB2SolrClientTest.java:

@@
-  private void startJettyAndWaitForAliveCheckQuery(SolrInstance solrInstance) throws Exception {
-    try (LogListener logListener =
-        LogListener.debug(LBSolrClient.class).substring(LBSolrClient.UPDATE_LIVE_SERVER_MESSAGE)) {
-      solrInstance.startJetty();
-      if (logListener.pollMessage(10, TimeUnit.SECONDS) == null) {
-        fail("The alive check query was not logged within 10 seconds.");
-      }
-    }
-  }
+  private void startJettyAndWaitForAlive(SolrInstance solrInstance, LBSolrClient lbClient)
+      throws Exception {
+    solrInstance.startJetty();
+
+    // Wait until the restarted node is actually usable again.
+    // This is more robust than waiting for a particular log message.
+    SolrQuery ping = new SolrQuery("*:*");
+    RetryUtil.retryOnBoolean(
+        15000, // total timeout
+        250,   // poll interval
+        () -> {
+          try {
+            QueryResponse r = lbClient.query(ping);
+            return r.getResults().getNumFound() == 10;
+          } catch (Exception e) {
+            return false;
+          }
+        });
+  }

Then update callers:

-      startJettyAndWaitForAliveCheckQuery(solr[1]);
+      startJettyAndWaitForAlive(solr[1], h.lbClient);

and:

-      startJettyAndWaitForAliveCheckQuery(solr[0]);
+      startJettyAndWaitForAlive(solr[0], h.lbClient);

This keeps the intent (“server comes back and LB client eventually uses it”) while removing the flakiness introduced by log timing.

Minimal alternative (if you want to keep log-based check)

If you prefer minimal change, increase the timeout and reduce brittleness:

• increase pollMessage(10, ...) to something like `pollMessage(3...

This pull request was created from Copilot chat.