We should completely remove usage of SecurityManager from tests and not need 
any other work-around.

There are only two usages:

1. 
activemq-kahadb-store/src/test/java/org/apache/activemq/store/kahadb/JournalArchiveTest.java
 
<https://github.com/apache/activemq/blob/94c3c3dac2316816c978218443ca9cf88a45a3e8/activemq-kahadb-store/src/test/java/org/apache/activemq/store/kahadb/JournalArchiveTest.java#L122>
2. 
activemq-unit-tests/src/test/java/org/apache/activemq/security/AbstractCachedLDAPAuthorizationMapLegacyTest.java
 
<https://github.com/apache/activemq/blob/94c3c3dac2316816c978218443ca9cf88a45a3e8/activemq-unit-tests/src/test/java/org/apache/activemq/security/AbstractCachedLDAPAuthorizationMapLegacyTest.java#L405>

There is already a PR to remove the one for the JournalArchiveTest (#1):
https://github.com/apache/activemq/pull/1357

-Matt

> On Jan 15, 2026, at 6:15 AM, Jean-Louis Monteiro <[email protected]> 
> wrote:
> 
> Hi all,
> 
> We used MRJAR in the Java 25 branch to get rid of the SecurityManager usage
> and use the new API to retrieve the subject mainly for audit logs.
> 
> But in tests, we also have things like System.setSecurityManager which has
> been marked as deprecated in Java 17.
> 
> Since Java 24, it permanently throws an exception hence the rework of some
> tests to avoid this in Java 25 ongoing work.
> 
> For versions 18-23, the flag to disable programmatic SecurityManager setup
> has been set to disallow which means that setSecurityManager() also throws
> an exception unless you explicitly authorize it.
> In the recent Github Actions work, we added Java 21 and 25 to the night
> builds in addition to Java 17. I made a PR to remove Java 25 for now,
> because we are still working on it on a separate branch so it's clear that
> nightly builds on Java 25 will always fail.
> 
> For Java 21, there is an open question because we have 2 options
> - remove it from the nightly build and stick with Java 17 until Java 25
> work is done
> - add the system property in surefire configuration to allow
> System.setSecurityManager() in tests
> 
> We can also rework the tests, but it's partially done already for Java 25
> and we are not far. I'm tempted to go with option 2 (system property), but
> I'd like to gather some thoughts.
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Reply via email to