Fix bug in JmxServerFeature resource registration

[roberttoyonaga]

This updates the resource bundle registration for the JMX server feature. This is needed to use remote JMX with password authentication.

This OpenJDK upstream PR resulted in the original resource registration going out-of-date: openjdk/jdk#22774
See this commit.

Without this fix the following error can be expected when attempting password authentication:

Exception in thread "main" java.lang.SecurityException: Authentication failed! java.util.MissingResourceException: Can't find bundle for base name sun.security.util.resources.security, locale en_US
		at java.base@25/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2012)
		at java.base@25/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1664)
		at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.localization.substitutions.Target_java_util_ResourceBundle$1.get(Target_java_util_ResourceBundle.java:123)
		at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.localization.substitutions.Target_java_util_ResourceBundle$1.get(Target_java_util_ResourceBundle.java:120)
		at org.graalvm.nativeimage.builder/com.oracle.svm.core.MissingRegistrationUtils.runIgnoringMissingRegistrations(MissingRegistrationUtils.java:122)
		at java.base@25/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:120)
		at java.base@25/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1529)
		at java.base@25/java.util.ResourceBundle.getBundle(ResourceBundle.java:848)
		at java.base@25/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1724)
		at java.base@25/sun.security.util.ResourcesMgr.getBundle(ResourcesMgr.java:54)
		at java.base@25/sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:40)
		at java.base@25/javax.security.auth.Subject$SecureSet.contains(Subject.java:1084)
		at java.base@25/java.util.Collections$SynchronizedCollection.contains(Collections.java:2315)
		at java.management@25/com.sun.jmx.remote.security.FileLoginModule.commit(FileLoginModule.java:329)
		at java.base@25/javax.security.auth.login.LoginContext.invoke(LoginContext.java:606)
		at java.base@25/javax.security.auth.login.LoginContext.login(LoginContext.java:461)
		at java.management@25/com.sun.jmx.remote.security.JMXPluggableAuthenticator.authenticate(JMXPluggableAuthenticator.java:166)
		at jdk.management.agent@25/sun.management.jmxremote.ConnectorBootstrap$AccessFileCheckerAuthenticator.authenticate(ConnectorBootstrap.java:232)
		at java.management.rmi@25/javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:231)
		at java.management.rmi@25/javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:198)
		at java.base@25/java.lang.reflect.Method.invoke(Method.java:565)
		at java.rmi@25/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:351)
		at java.rmi@25/sun.rmi.transport.Transport.serviceCall(Transport.java:166)
		at java.rmi@25/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:543)
		at java.rmi@25/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:744)
		at java.rmi@25/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:623)
		at java.base@25/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
		at java.base@25/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
		at java.base@25/java.lang.Thread.runWith(Thread.java:1487)
		at java.base@25/java.lang.Thread.run(Thread.java:1474)
		at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:832)
		at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:808)
    . . .

Steps to reproduce can be found here https://github.com/roberttoyonaga/RJMXTests/tree/main/Standalone (the SSL configuration can be ignored).

This bug affects the GraalVM for JDK 25 release branch (https://github.com/oracle/graal/tree/release/graal-vm/25.0) as well and should be backported to it.

[fniephaus]

Thanks for the PR, @roberttoyonaga!

@zapster what's the best way to protect from such issues in the future? Should we annotate the feature with @BasedOnJDKFile or so?

[zapster]

@zapster what's the best way to protect from such issues in the future? Should we annotate the feature with @BasedOnJDKFile or so?

I think for things link resource/reflection config, @BasedOnJDKFile is not really feasible. First, we have a lot of them and even if we could annotate them all (which already assumes that there is a reasonable code section in the JDK we can guard against, which I'm not sure is really the case, at least it is not trivial), it would probably result in a lot of reviewing overhead.

In in situations like this, I think the best protection is having a unittest/integration test for the feature. @roberttoyonaga what do you think? Is it possible to write a unit test that triggers the issue? Alternatively, do you think it would be worth adding (a version of) your reproducer as an integration test?

[zapster]

It bugs me that we don't detect resource registrations that are just missing. Turns out that we realize that something is off. If we run with

mx helloworld --enable-monitoring=jmxserver -H:+TraceLocalizationFeature

we actually see that something is wrong, but it is hidden in a lot of clutter

...
Adding bundle jdk.internal.agent.resources.agent, locale en_US with condition ConfigurationCondition(type=class java.lang.Object, runtimeChecked=true)
Adding bundle jdk.internal.agent.resources.agent, locale en with condition ConfigurationCondition(type=class java.lang.Object, runtimeChecked=true)
The bundle named: sun.security.util.Resources, has not been found. If the bundle is part of a module, verify the bundle name is a fully qualified class name. Otherwise verify the bundle path is accessible in the classpath.
Adding bundle sun.util.resources.cldr.CalendarData, locale  with condition ConfigurationCondition(type=class java.lang.Object, runtimeChecked=true)
Adding bundle sun.util.resources.cldr.CurrencyNames, locale  with condition ConfigurationCondition(type=class java.lang.Object, runtimeChecked=true)
...

@fniephaus I think we could do better, e.g., have a flag where errors are fatal and use that for (most of) our gate jobs?

[fniephaus]

I think we could do better

Thanks, @zapster. I agree. Let's get this fix in and make this better in a follow up.

[fniephaus]

LGTM

[roberttoyonaga]

Is it possible to write a unit test that triggers the issue?

@zapster Yes I agree that a unit test would be the best way to catch these problems. We currently have multiple unittests testing remote JMX, but none checking ssl and authentication.

@fniephaus I made a PR adding authentication and SSL tests for remote JMX a while ago: #6275
It didn't end up being integrated, but I can't remember why. Should we revisit it?

[fniephaus]

but I can't remember why. Should we revisit it?

Yes, I remember...let me comment on the PR.