Update 25.0.0.10-beta-post into draft

posts/2025-09-23-25.0.0.10-beta.adoc

@@ -82,7 +82,7 @@ See also link:{url-prefix}/blog/?search=beta&key=tag[previous Open Liberty beta
 [#overrideLibrary]
 == OverrideLibrary support for application classloader
 
-The 25.0.0.10-beta release introduces a new type of library reference for configuring an application’s `<classloader/>`: the override library reference. The override library reference is similar to a private library reference because class instances remain unique to the application’s classloader. The key difference is the search order. With an override library reference, the library class path is searched before the application’s own class path, which allows the library path to override classes that are already included in the application.
+The 25.0.0.10-beta release introduces a new type of library reference for configuring an application’s `<classloader/>`that can be used to configure an the override library reference. The override library reference is similar to a private library reference because class instances remain unique to the application’s classloader. The key difference is the search order. With an override library reference, the library class path is searched before the application’s own class path, this allows the library path to override classes that are already included in the application.
 
 For example, suppose a `<webApplication/>` contains a class such as `org.acme.needs.fix.SomeImpl` that must be overridden to resolve an issue. If rebuilding the application to include the fix is difficult or undesirable, you can instead build a new library JAR (for example, someImplFix.jar) with the corrected class files. The following `server.xml` configuration shows how to use an `overrideLibraryRef` to apply the fix without rebuilding the application:
 
@@ -138,7 +138,7 @@ When you use the `CompletableFuture` and `SubmissionPublisher` classes in Java 2
 
 You can avoid this issue by using one of the following approaches:
 
-  . Use the `CompletableFuture` provided in Liberty’s Jakarta Concurrency implementation, which does not have this limitation. An easy way to do this is with a link:https://www.ibm.com/docs/en/was-liberty/core?topic=manually-configuring-managed-executors[DefaultManagedExecutorService] and the link:https://jakarta.ee/specifications/concurrency/3.1/apidocs/jakarta.concurrency/jakarta/enterprise/concurrent/managedexecutorservice#supplyAsync(java.util.function.Supplier)[supplyAsync or runAsync] methods.
+  . Use the `CompletableFuture` class provided in Liberty’s Jakarta Concurrency implementation, which does not have this limitation.You can use the `CompletableFuture` class with a link:https://www.ibm.com/docs/en/was-liberty/core?topic=manually-configuring-managed-executors[DefaultManagedExecutorService] instance and either the link:https://jakarta.ee/specifications/concurrency/3.1/apidocs/jakarta.concurrency/jakarta/enterprise/concurrent/managedexecutorservice#supplyAsync(java.util.function.Supplier)[supplyAsync] method or the runAsync method.
   . Explicitly set the `ForkJoinPool.commonPool` parallelism value to whatever you need, `-Djava.util.concurrent.ForkJoinPool.common.parallelism=N` (where N is the minimum number of threads needed)
   . Explicitly set the `ForkJoinPool.commonPool` parallelism value to the desired number of threads by using the system property,
   `-Djava.util.concurrent.ForkJoinPool.common.parallelism=N` (where N is the minimum number of threads required).