You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Jean-Louis Monteiro <jl...@tomitribe.com> on 2026/01/15 12:15:32 UTC
SecurityManager in ActiveMQ
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
Re: SecurityManager in ActiveMQ
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Yes, this is temporary because anyways, we are working on it for Java 25.
Half of the work is done. The LDAP is not used for your information because
the 2 tests using it are @Ignore (I already checked it before sending the
email).
Adding the system property is a pragmatic approach to start getting nightly
builds with Github Actions. For the moment we are blind in some regards.
I've created a PR for it: https://github.com/apache/activemq/pull/1612
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Sat, Jan 17, 2026 at 5:39 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Matt
>
> Fully agree, but my understanding of Jean-Louis' proposal is to move faster
> on Java 25 build by adding this property as transition period.
>
> We are all frustrated about flaky tests, unstable build, and it's even
> worse with Java 25. So I think it's great to introduce this property now,
> to give us team to remove the SecurityManager later when the other part of
> the build with Java 25 is also ok (which is not the case today).
>
> So, I'm with you, but I'm in favor of moving fast in stabilizing our build,
> as it impacts all PRs.
>
> Regards
> JB
>
> On Fri, Jan 16, 2026 at 4:35 PM Matt Pavlovich <ma...@apache.org>
> wrote:
>
> > 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 <
> > jlmonteiro@tomitribe.com> 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
> >
> >
>
Re: SecurityManager in ActiveMQ
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Matt
Fully agree, but my understanding of Jean-Louis' proposal is to move faster
on Java 25 build by adding this property as transition period.
We are all frustrated about flaky tests, unstable build, and it's even
worse with Java 25. So I think it's great to introduce this property now,
to give us team to remove the SecurityManager later when the other part of
the build with Java 25 is also ok (which is not the case today).
So, I'm with you, but I'm in favor of moving fast in stabilizing our build,
as it impacts all PRs.
Regards
JB
On Fri, Jan 16, 2026 at 4:35 PM Matt Pavlovich <ma...@apache.org> wrote:
> 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 <
> jlmonteiro@tomitribe.com> 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
>
>
Re: SecurityManager in ActiveMQ
Posted by Matt Pavlovich <ma...@apache.org>.
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 <jl...@tomitribe.com> 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
Re: SecurityManager in ActiveMQ
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
That was my choice as well, so if no one objects, I'll create a PR
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Jan 15, 2026 at 7:29 PM Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:
> The system property seems fine for now as it's just going to be temporary
> until the work is finished for JDK 25 and then the flag can be removed.
>
> On Thu, Jan 15, 2026 at 7:15 AM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> 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
> >
>
Re: SecurityManager in ActiveMQ
Posted by Christopher Shannon <ch...@gmail.com>.
The system property seems fine for now as it's just going to be temporary
until the work is finished for JDK 25 and then the flag can be removed.
On Thu, Jan 15, 2026 at 7:15 AM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> 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
>
Re: SecurityManager in ActiveMQ
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Jean-Louis,
Thanks for the comprehensive email.
I also prefer using a system property for now. This approach allows us to
move forward smoothly while we complete the remaining work.
Regards,
JB
On Thu, Jan 15, 2026 at 1:15 PM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> 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
>