martint/jmxutils

Exporting JMX mbeans made easy

jmxutils's Issues

Registering with Guice TypeListener

I am very keen to switch to this JMX enabling library and move away from pojo-mbean, as the features here are a more natural fit. However, I am having trouble letting the export process "discover" managed beans as they are injected, a pattern I have used to great effect previously.
Using jmxutils, the following works:

 private ExportBinder exporter;

 @Override
    protected void configure() {
        bind(MBeanServer.class).toInstance(ManagementFactory.getPlatformMBeanServer());
        install(new MBeanModule());
        exporter = ExportBinder.newExporter(binder());
        exporter.export(MyClass.class).withGeneratedName();
    }

but using Listeners doesn't (I'm using the ManagedBean annotation to "mark" my class...assume that MyClass has that annotation):

   private ExportBinder exporter;

   @Override
    protected void configure() {
        bind(MBeanServer.class).toInstance(ManagementFactory.getPlatformMBeanServer());
        bindListener(Matchers.any(), new JmxTypeListener());
        install(new MBeanModule());
        exporter = ExportBinder.newExporter(binder());
    }

    private class JmxTypeListener implements TypeListener {
        @Override
        public <I> void hear(TypeLiteral<I> type, final TypeEncounter<I> encounter) {

            final Class<? super I> rawType = type.getRawType();

            if (rawType.isAnnotationPresent(ManagedBean.class)) {
                exporter.export(rawType).withGeneratedName(); //this seems to have no effect!
...

Everything executes as expected, but no entry shows up in the jmx console for the second approach. Is it too late to export beans by the time the listener is "hearing" bindings? Is there any workaround that means I don't have to explicitly export beans by type?

Why shaded?

Why has guava and paranamer been shaded in? This makes this otherwise pretty lightweight library bloated and at least for myself makes it less desirable to re-use over re-implementation.

I get that some folks it may be simpler with a single jar, but in that case a shaded "attached" artifact may be simpler, and leaves those that already have rigid controls over dependencies the flexibility to use the library with-out the shaded inflation.

Bump guava version to 30.0+ to fix CVE-2020-8908

Hi there,

Our project is using jmxutils and our dependency vulnerability scanning is reporting a Guava vulnerability CVE-2020-8908 that's being brought in by jmxutils. I'm not sure if the project is still active, but is there any possibility the version of Guava could be bumped to resolve this? Because Guava is shaded we can't upgrade the version on our end.

Thanks!

jmxutils don't include the license file

Not available LICENSE file in source directory structure
Please. Added license and copyright notice.
the fedora pakaging guideline is very strictly precise about this problem
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Text
thanks
regards

The README.md reflects 1.11 which does not have ExportBinder

<dependency>
    <groupId>org.weakref</groupId>
    <artifactId>jmxutils</artifactId>
    <version>1.11</version>
</dependency>

The maven dependency does not reflect the correct class since ExportBinder is unavailable in 1.11. Have checked version 1.18 where it is available. May be you could point to the latest considering the other code samples are up to date

Custom ManagedAnnotation ?

We're looking at feeding some of our instrumentation into a time series database, in addition to exposing it through JMX.

We'll want some of our stats objects to maintain two sets of data: one using decaying values for JMX, another using minute buckets for the time series database. So we'd have @Managed for JMX only, a custom @Report (which would be @ManagedAnnotation) for both JMX and database, and a custom @ReportOnly (which would not be @ManagedAnnotation) for database only.

So, to implement this, would it make sense for jmxutils to support custom replacements for @ManagedAnnotation? For example, add a constructor:

public MBeanExporter(MBeanServer server)
{
    this(server, ManagedAnnotation.class);
}

public MBeanExporter(MBeanServer server, 
                     Class<? extends Annotation> managementAnnotation)

Then I could define a custom ManagedAnnotation and use jmxutils to populate a MBeanServer that feeds the time series database.

I'm willing to do the coding, but I'd first like your take on the idea.

Create JMX generated name with a provider

JMX utils should include an API to generate names with a provider of some sort. This is useful if the JMX name needs to be based on an attribute of the instance of the exported class.

Add support for Java8 ByteCode

@Managed operations with arguments throw an exception during parameter name extraction.

This code should used more generic paranamer code. See Swift for an example https://github.com/facebook/swift/blob/master/swift-codec/src/main/java/com/facebook/swift/codec/metadata/ReflectionHelper.java#L241

Caused by: java.lang.ArrayIndexOutOfBoundsException: 74340
    at org.weakref.jmx.internal.paranamer.BytecodeReadingParanamer$ClassReader.readUnsignedShort(BytecodeReadingParanamer.java:687) ~[jmxutils-1.18.jar:na]
    at org.weakref.jmx.internal.paranamer.BytecodeReadingParanamer$ClassReader.accept(BytecodeReadingParanamer.java:536) ~[jmxutils-1.18.jar:na]
    at org.weakref.jmx.internal.paranamer.BytecodeReadingParanamer$ClassReader.access$200(BytecodeReadingParanamer.java:311) ~[jmxutils-1.18.jar:na]
    at org.weakref.jmx.internal.paranamer.BytecodeReadingParanamer.lookupParameterNames(BytecodeReadingParanamer.java:102) ~[jmxutils-1.18.jar:na]
    at org.weakref.jmx.internal.paranamer.BytecodeReadingParanamer.lookupParameterNames(BytecodeReadingParanamer.java:68) ~[jmxutils-1.18.jar:na]
    at org.weakref.jmx.MBeanOperationBuilder.build(MBeanOperationBuilder.java:86) ~[jmxutils-1.18.jar:na]

Allow for non-javabean attribute

We should support non-javabean attributes like:

ThreadPoolExecutor.allowsCoreThreadTimeOut
ThreadPoolExecutor.allowCoreThreadTimeOut(true)

Refresh @Nested objects

@Nested objects are only fetched once and used for all future requests. This makes it difficult to use immutable stat objects that are refreshed periodically. I would be nice if jmxutils supported fetching the object each time. This should be optional since fetching the object for every mbean attribute request could be very expensive. Additionally, it would be nice to jmxutils could cache the objects for a configurable period.

instructions on pulling with maven

(Apologies -- this started as a request to publish to maven central; I failed to look hard enough!)

Please provide instructions (sample dependency XML block) for pulling from maven. Great looking project.

Implement TestingMBeanServer.queryNames

That'd be useful when TestingMBeanServer is used to expose metrics using Airlift

operation param naming and instance objectname delegation and other stuff

jmxutils is pretty nice :-)

I did find that it was missing the ability to specify name/description for operation names (or for that matter the mbeans themselves). This is minor IMO for mbeans themselves, though nice to have, but for operations is often hard to figure out what the parameters are for with the default names, so I think its important to allow that metadata to get expressed.

Also, any idea how difficult it would be to allow an object instance to inform the library what objectname it should use, or to perhaps even delegate the mbean class which should provide jmx access for it? And really I'm taking more about the guice integration (which is really great btw), but it looks like it binds the mapping to strings very early, before an instance is ever created.

Also, any ideas on how to expose javabean values as openmbean datatypes similar to how MXBeans do? I see there is @flatten and @nested which is nice, but it would be nicer if it would just translate on the fly to openmbean data formats like MXBeans do.

Anyways, just some thoughts... if you have any ideas I'd like to hear them. I might get inspired to go hack this stuff in.

Source files without license headers

Hi,
The following source files are without license headers:

./src/main/java/org/weakref/jmx/JmxException.java
./src/main/java/org/weakref/jmx/ManagedAnnotation.java
./src/main/java/org/weakref/jmx/ObjectNameBuilder.java
./src/main/java/org/weakref/jmx/ObjectNames.java
./src/main/java/org/weakref/jmx/guice/ExportBinder.java
./src/main/java/org/weakref/jmx/guice/ExportBuilder.java
./src/main/java/org/weakref/jmx/guice/MapExportBinder.java
./src/main/java/org/weakref/jmx/guice/MapMapping.java
./src/main/java/org/weakref/jmx/guice/MapNamingFunction.java
./src/main/java/org/weakref/jmx/guice/MapObjectNameFunction.java
./src/main/java/org/weakref/jmx/guice/NamingFunction.java
./src/main/java/org/weakref/jmx/guice/ObjectNameFunction.java
./src/main/java/org/weakref/jmx/guice/SetExportBinder.java
./src/main/java/org/weakref/jmx/guice/SetMapping.java
./src/main/java/org/weakref/jmx/guice/StringMapExportBinder.java
./src/main/java/org/weakref/jmx/testing/TestingMBeanModule.java
./src/main/java/org/weakref/jmx/testing/TestingMBeanServer.java

./src/test/java/org/weakref/jmx/AbstractMbeanTest.java
./src/test/java/org/weakref/jmx/CustomAnnotationObject.java
./src/test/java/org/weakref/jmx/TestExports.java
./src/test/java/org/weakref/jmx/TestMBeanBuilder.java
./src/test/java/org/weakref/jmx/TestObjectNameBuilder.java
./src/test/java/org/weakref/jmx/TestObjectNames.java
./src/test/java/org/weakref/jmx/TestUnexporter.java

Please, confirm the licensing of code and/or content/s, and add license headers
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Clarification

Thanks in advance
Regards

MBeanExporter: memory leak related to ManagedClasses registry

ManagedClasses that are registered in exportedManagedClasses are never unregistered. This is causing an accumulation of memory.