[AMQ-9563] JDK 21 support: Remove usage of java.security.AccessController from ActiveMQConnectionFactory

[mattrpav]

• java.security.AccessController is deprecated for removal
• Keep try-catch-log around property lookup in the event a security exception is thrown on older JDKs.
• Document JDK 21 refactor TODO with a comment for future refactor for JAAS API change

[cshannon]

I know that this PR doesn't change this but it's weird to me that the code just logs a debug if an exception is thrown if properties are unreadable. I would think that exception would be a bigger deal and should be thrown to error out or at least logged as a warn or error. That would be a change outside of the scope of this PR of course, I just wanted to note that it's probably handled poorly.

[mattrpav]

@cshannon Good point. I had opted to leave the logging level alone. If there were an exception, it would be a SecurityException (in future JDKs this will cease to be a code path), NPE, or some fatal RuntimeException like OOM, interrupted, etc.

I'd be in favor of changing the level here to a WARN or ERROR. Perhaps best as a follow-on for 7.x to not break any existing log capture?

[cshannon]

I'd be in favor of changing the level here to a WARN or ERROR. Perhaps best as a follow-on for 7.x to not break any existing log capture?

We should probably just change it in 6.2.0 or 6.3.0 etc, because with removing the security check it's pretty unlikely to fail. And without the security check if it does fail there's probably something much more serious going on if you can't check a system roperty, so I would think logging it as a WARN level would make sense and maybe in 7.x actually throw an exception.

[mattrpav]

I'd be in favor of changing the level here to a WARN or ERROR. Perhaps best as a follow-on for 7.x to not break any existing log capture?

We should probably just change it in 6.2.0 or 6.3.0 etc, because with removing the security check it's pretty unlikely to fail. And without the security check if it does fail there's probably something much more serious going on if you can't check a system roperty, so I would think logging it as a WARN level would make sense and maybe in 7.x actually throw an exception.

A quick check confirmed that the logger only exists for these two log messages, it may be better to get rid of the logger completely in 7.x and throw an exception?

1. Merge this as-is in 6.2.0 (Leave log level alone)
2. Remove logger in 7.x and throw an exception

ref: AMQ-9586