ReloadConfigCmdRegistration and ConfigWorkspaceJmxRegistration fail to register the MBean on public when an author is already running in the same container (i.e. in our integration tests):

Caused by: javax.management.InstanceAlreadyExistsException: info.magnolia.microprofile:type=config,name=ReloadConfigCommand
	at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
	at info.magnolia.objectfactory.guice.microprofile.mxbean.ReloadConfigCmdRegistration.registerMXBean(ReloadConfigCmdRegistration.java:57)

Workaround

A  workaround that logs these errors instead of throwing a runtime exception is in place.

Implementation note

(Note from aichimescu copied over from Slack )

"The ReloadConfigCmdMXBean is responsible for reloading the microprofile configuration without restarting the instance. In Saas, the config files are being watched by the vitals, and if a change is detected, we trigger a refresh.

The ConfigWorkspaceJMXBean is responsible for locking/unlocking the config workspace. Locking is being triggered at startup. We should not need this bean in dx-core since we don't need to lock or unlock the jcr workspace.

As for suggestions, since I am not a fan of using the jmx for this, I would convert the mxBeans to rest-endpoints that are only visible to the sys-admins. For reloading the microprofile config, this implies a change in the vitals-webapp as well in order to properly form the base-url (but I think that we have the subscription-id as a param)."