Require opt-in for using unnamespaced mbean exports #67
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It was deprecated since bd231bf commit, i.e. for over decade.
findepi
force-pushed
the
findepi/safety
branch
from
e16b1e9 to
ac91883
Compare
wendigo
reviewed
Jan 7, 2026
wendigo
reviewed
Jan 7, 2026
Some applications exports mbeans in one place, from one class loader, and so they do not need namespacing as class name-generated mbean names do not collide. Some applications use multiple class loaders and therefore require additional configuration for exporting mbeans safely. The `MBeanModule` provides sufficient configuration options, allowing users to bind `ObjectNameGenerator`, but its default behavior turned out to be error-prone at least in projects such as Trino. It seems safer to require explicit opt-in into unnamespaced exports. This commit deprecates `MBeanModule` constructor in favor of named factory methods for explicit declaration whether default `ObjectNameGenerator` should be used, or custom one will be provided. The "for custom" factory creates a module that will fail to load unless a custom `ObjectNameGenerator` is bound. The "for unnamespaced" creates a module with default `ObjectNameGenerator`. The factory name is meant to be thought-provoking and therefore the name generator bound this way is not rebindable. The `new MBeanModule()` constructor is kept, but deprecated. It supports the original behavior allowing users to rebind name generator.
findepi
force-pushed
the
findepi/safety
branch
from
ac91883 to
efaf070
Compare
wendigo
approved these changes
Jan 7, 2026
Contributor
|
@martint ptal |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some applications exports mbeans in one place, from one class loader,
and so they do not need namespacing as class name-generated mbean names
do not collide. Some applications use multiple class loaders and
therefore require additional configuration for exporting mbeans safely.
The
MBeanModuleprovides sufficient configuration options, allowingusers to bind
ObjectNameGenerator, but its default behavior turned outto be error-prone at least in projects such as Trino. It seems safer to
require explicit opt-in into unnamespaced exports.
This commit deprecates
MBeanModuleconstructor in favor of namedfactory methods for explicit declaration whether default
ObjectNameGeneratorshould be used, or custom one will be provided.The "for custom" factory creates a module that will fail to load unless
a custom
ObjectNameGeneratoris bound.The "for unnamespaced" creates a module with default
ObjectNameGenerator. The factory name is meant to be thought-provokingand therefore the name generator bound this way is not rebindable.
The
new MBeanModule()constructor is kept, but deprecated. It supportsthe original behavior allowing users to rebind name generator.
Motivation