GithubHelp home page GithubHelp logo

jmxutils's Introduction

Example

class ManagedObject
{
    @Managed
    public int getValue()
    {
       ...
    }

    @Managed
    public void setValue(int value)
    {
       ...
    }

    @Managed(description="do the operation")
    public void operation()
    {
       ...
    }
}

...
MBeanExporter exporter = new MBeanExporter(ManagementFactory.getPlatformMBeanServer());
exporter.export("test:name=X", new ManagedObject());
exporter.unexport("test:name=X");

Guice support

Injector injector = Guice.createInjector(
    new MBeanModule(), // used to trigger registration of mbeans exported via ExportBinder
    new AbstractModule() {
            @Override
            protected void configure() {
               // MBeanModule expects an MBeanServer to be bound
               bind(MBeanServer.class).toInstance(ManagementFactory.getPlatformMBeanServer());

               ExportBinder exporter = ExportBinder.newExporter(binder());
               exporter.export(AnotherManagedObject.class).as("test:name=\"Z\"");
               
               // You can use a standardized naming scheme for singletons if you wish.
               // See ObjectNames.generatedNameOf(Class<?>) for the naming scheme.
               exporter.export(ManagedSingleton.class).withGeneratedName();
            }
    }, ...);

Custom annotations

You can use your own annotations instead of @Managed to tag methods. To do so, you need to tag the annotation with the org.weakref.jmx.ManagedAnnotation meta annotation.

@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.METHOD })
@ManagedAnnotation
public @interface CustomAnnotation
{
    String description() default "";
    String type() default "";
}

class ManagedObject
{
    @CustomAnnotation(description="foo", type="counter")
    public int getValue()
    {
       ...
    }
}

If the custom annotation has an attribute "description" of type String, it will be used as the description of the jmx method or attribute.

Advanced Usage

jmxutils has advanced support for nested managed objects. This first example demonstrates the @Nested annotation:

public class NestedExample
{
   private final NestedObject nestedObject = new NestedObject();

   @Nested
   public NestedObject getNestedObject()
   {
       return nestedObject;
   }

   public static final class NestedObject {
       @Managed
       public String getValue() {
           return "someValue";
       }
   }
}

When the @Nested annotation is applied to a managed getter, jmxutils simply retrieves the value from the getter and exposes all managed attributes and operations prefixed with the getter name. In the example above, the exposed MBean will have an attribute named "NestedObject.Value" and an operation named "NestedObject.doSomething".

Next the example demonstrates the @Flatten annotation.

public class FlattenedExample
{
   private final FlattenedObject flattenedObject = new FlattenedObject();

   @Flatten
   public FlattenedObject getFlattenedObject()
   {
       return flattenedObject;
   }

   public static final class FlattenedObject {
       @Managed
       public String getValue() {
           return "someValue";
       }
       @Managed
       public void doSomething() {
           System.out.println("something");
       }
   }
}

The @Flatten annotation works like the @Nested annotation except the exposed attributes and operation are not prefixed with the getter name. In the example above, the exposed MBean will simply have an attribute named "Value" and an operation named "doSomething" without any prefix.

Maven dependency

To use jmxutils in maven projects:

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

Current version: Maven Central

License

Licensed under the Apache License, Version 2.0 (the "License")

You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

jmxutils's People

Contributors

arosien avatar cberner avatar dain avatar dblevins avatar electrum avatar frsyuki avatar johngmyers avatar martint avatar mattstep avatar mehdi-khosravi avatar nezihyigitbasi avatar oskar-szwajkowski avatar randgalt avatar stevenschlansker avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jmxutils's Issues

Allow for non-javabean attribute

We should support non-javabean attributes like:

ThreadPoolExecutor.allowsCoreThreadTimeOut
ThreadPoolExecutor.allowCoreThreadTimeOut(true)

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!

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.

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

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.

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.

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

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.

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?

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.

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]

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.