2 Replies Latest reply on Jul 17, 2013 8:30 PM by genman

    Common management annotations for JBoss projects?

    pilhuhn

      RHQ has a plugin generator, that I've been enhancing a bit in the last few days(*).

      Triggered by that effort I came back into an effort that we started together with

      Infinispan to have annotations on methods / fields to provide the metadata for

      management. E.g.

       

      public class Foo {
          @Metric(description = "Just a foo", dataType = DataType.TRAIT)
         String lastCommand;
      
          @Metric(description = "How often was this bean invoked", displayType = DisplayType.SUMMARY, 
              measurementType = MeasurementType.DYNAMIC,
              units = Units.SECONDS)
          int invocationCount;
      
         @Operation(description = "Decrease the counter")
         public void decreaseCounter(@Parameter(description = "How much to decrease?", name = "by") int by) {
             invocationCount -= by;
         }
      }
      

       

      This has since diverged as ISPN has a different set of annotations to mark stuff to be exposed via jmx.

      And then there is as7 with DMR, that also has a way of providing that metadata. (And I guess Fuse does a similar job ).

       

      I would like to discuss initiate a common set of annotations (or other metadata) that we could use all over JBoss to create plugins and management interfaces etc. from it, so that a writer of an app only needs to use this set of annotations and we can then create DMR-resouce-description,  RHQ plugins etc. from it (may also help with automatic UI generation).

       

      Clear requirements for RHQ are

      * units for metrics

      * Measurement type for metrics (trends up/down, dynamic)

      and I guess a few more that I just forgot

        • 1. Re: Common management annotations for JBoss projects?
          dmlloyd

          I've been working on annotations for WildFly.  The set we have defines management resources and attributes, and also the infrastructure required to support them.  The project is here: https://github.com/wildfly/core-management until or unless Jason kicks it out of there

          • 2. Re: Common management annotations for JBoss projects?
            genman

            I'd be awsome if:

            • JBoss ('WildFly') did the right thing with javax.management annotations (http://www.javaworld.com/community/node/1164) via CDI...I wrote a CDI extension that works great, but I haven't released yet as open source since I'm not sure if people seem to care about CDI/JMX that much: https://community.jboss.org/thread/220963 - although maybe I haven't found the right audience? This seems like a no brainer.
            • RHQ had a tool to generate a descriptor for rhq-agent.xml that used the JMX meta data. I wrote a JMX plugin generator that I use, although it's pretty crude. It works off of JMX metadata passed through the MBeanServer. It did a fine job of generating a plugin for standalone HornetQ.

             

            For providing RHQ metadata it wants, JMX offers 'descriptors' (http://docs.oracle.com/javase/6/docs/api/javax/management/Descriptor.html), which should work for configuring units, trendsup, summary, etc.

            You annotate an attribute using something like this:

             

             

            @DescriptorFields({"units=bytes", "org.jboss.rhq.trending=up"})
            

             

            Although this is not as great as custom annotations...For CDI support, you can maybe create a bunch of WildFly/RHQ custom annotations that are translated into standard JMX descriptors.

             

            Maybe these annotations could offer suggestions in terms of alert configuration as well? For example, "maxValue" or "minValue" are defined already.

             

            The workflow would be:

            • App writer comes up with product, puts annotations in their code, which is exposed by JBoss/Tomcat/Java via JMX
            • Operations/admin guy runs the plugin generator on a running system to capture the MBeans
            • Newly created plugin is edited (hopefully minimally), and then deployed to RHQ