[
https://issues.apache.org/jira/browse/ARTEMIS-5711?focusedWorklogId=988353&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-988353
]
ASF GitHub Bot logged work on ARTEMIS-5711:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Oct/25 11:51
Start Date: 22/Oct/25 11:51
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #5993:
URL: https://github.com/apache/activemq-artemis/pull/5993#discussion_r2451826061
##########
tests/compatibility-tests/src/test/java/org/apache/activemq/artemis/tests/compatibility/MultiVersionReplicaTest.java:
##########
@@ -59,12 +59,16 @@ public class MultiVersionReplicaTest extends ClasspathBase {
@Parameters(name = "main={0}, backup={1}")
public static Collection getParameters() {
List<Object[]> combinations = new ArrayList<>();
- combinations.add(new Object[]{TWO_TWENTYTWO_ZERO, SNAPSHOT});
- combinations.add(new Object[]{SNAPSHOT, TWO_TWENTYTWO_ZERO});
- combinations.add(new Object[]{TWO_SEVENTEEN_ZERO, SNAPSHOT});
- combinations.add(new Object[]{SNAPSHOT, TWO_SEVENTEEN_ZERO});
- combinations.add(new Object[]{TWO_EIGHTEEN_ZERO, SNAPSHOT});
- combinations.add(new Object[]{SNAPSHOT, TWO_EIGHTEEN_ZERO});
+
+ if (getJavaVersion() <= 22) {
+ // Old 2.x servers fail on JDK23+ without workarounds.
+ combinations.add(new Object[]{TWO_TWENTYTWO_ZERO, SNAPSHOT});
+ combinations.add(new Object[]{SNAPSHOT, TWO_TWENTYTWO_ZERO});
+ combinations.add(new Object[]{TWO_SEVENTEEN_ZERO, SNAPSHOT});
+ combinations.add(new Object[]{SNAPSHOT, TWO_SEVENTEEN_ZERO});
+ combinations.add(new Object[]{TWO_EIGHTEEN_ZERO, SNAPSHOT});
+ combinations.add(new Object[]{SNAPSHOT, TWO_EIGHTEEN_ZERO});
+ }
Review Comment:
To be clear, we will still be validating those combinations using Java 17
and 21 in CI on each commit, so noone is going to miss any related breakage the
tests could currently catch.
I went through all the invididual test failures from the initial runs on JDK
25 and picked out the bits that failed so the rest could continue. So we cant
just add that one back, it doesnt work as things are.
The only possibility that might make it work would be to disable the
AuditLogging loggers for each specific version. However those versions all use
JBL rather than SLF4J+Log4J and so doing that would require adding jars to the
bootclasspath, and others to the regular classpath (should already be there),
adding a config file, and setting some properties at JVM startup. The only way
I see of doing these things would be having test-specific surefire invocations
and config. I dont personally think its worth the time or uglyness that would
result. Plus no version below 2.44.0 will be usable on future JDKs once the
SecurityManager related APIs are actually removed. To keep testing these
combinations is going to require multiple JVMs or taking a different approach.
Issue Time Tracking
-------------------
Worklog Id: (was: 988353)
Time Spent: 2.5h (was: 2h 20m)
> Enable support for building and running on Java 25
> --------------------------------------------------
>
> Key: ARTEMIS-5711
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5711
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Affects Versions: 2.43.0
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.44.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The Java SecurityManager was deprecated in Java 17 for removal, with no aim
> to replace the functionality. The Subject class also uses parts of the
> SecurityManager API, but it has its own usages beyond the SecurityManager
> functionality, so replacement functionality for the affected methods were
> added in Java 18 in the Subject.current() and Subject.callAs(..) methods.
> Java 23 began the process for removing the SecurityManager implementation,
> reimplementing the Subject methods with both the old and newer behaviours,
> and making Subject.getSubject(..) throw UnsupportedOperationException unless
> an option flag is used to enable support for a SecurityManager (still without
> actually needing to have an SM in use). [Java 24 actually removed the
> SecurityManager implementation|https://openjdk.org/jeps/486] , and made
> Subject.getSubject() always throw UnsupportedOperationException. As a result
> of these changes, building and testing Artemis does not work on Java 23+
> currently, and there are issues running on Java 23+ without at least
> disabling the AuditLogging functionality that uses Subject.getSubject(..).
> These issues can be seen discussed in the referenced ARTEMIS-4975 and
> ARTEMIS-5374. Though the other SecurityManager APIs are still present and
> 'functional' (effectively passthroughs), the APIs will be removed in a future
> JDK which will itself present another issue to building and running on those
> JDKs
> This Jira seeks to enable building/testing and running on Java 25 and beyond
> by addressing these issues. To achieve this, references to the
> SecurityManager / Subject APIs affected will be contained to a wrapper shim,
> with an implementation using the old methods targeting Java 17-23, and a
> second shim implementation using the new Subject methods (and not using any
> SecurityManager methods at all) targeting Java 24+ and thus enabling Java 25
> support and avoiding issues when the old APIs are later removed. (NOTE: on
> Java 23 this approach will still requiring either the flag to enable
> SecurityManager support, or disabling the audit logging to avoid it calling
> Subject.getSubject(..), if not just upgrading to e.g a supported Java 25
> release)
> Whilst it will still be possible to run/build/test on Java 17+, a side effect
> of this approach will be requiring that releases are created using Java 25,
> which was [discussed and agreed on the mailing
> lists|https://lists.apache.org/thread/7vspfpmfnfqd6fmvpjzm0kr59b5dm9j2].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
