On Tue, Jul 23, 2013 at 5:00 AM, Lukas Krejci <lkrejci@redhat.com> wrote:

The trick is that at runtime, the annotations don't exist anymore. They are only used at compile time to generate "normal" plugin code that the RHQ then sees and uses as normal.

But if I were do it, I would have the annotations present at runtime and not have the step of generating the descriptor nor the glue code, plus supporting resource injection would make coding a plugin a lot nicer.

@Service(name='Counter',discovery=CounterDiscovery.class,singleton=true,parent='CounterTree')
public class CounterComponent {
    @Inject // would default to the parent component
    CounterTreeComponent parent;
    @Inject
    ContentServices content; // no need to do getResourceContext().getContentContext().getContentServices() ...
}

public class CounterDiscovery implements ... { }

The plugin definition would go into your package-info.java . The upside is no XML required to write a plugin, no code generation step, no confusion that your XML matches your code. The only minus is really the complexity of testing in Maven, but you could use a pattern from Arquillian to do that.

Obviously for injection support, you'd want to use CDI to do it. I don't know if CDI is memory hungry or not, but it would be worth considering.

As you know, there is a connected, if somewhat distinct, effort to come up with a common set of management annotations across JBoss products, where I think the JMX management annotations (either JMX 1 or 2) will be considered.
https://community.jboss.org/message/828515

I set off to implement the annotation processor (together with a set of annotations) in an attempt to have a clear set of requirements from the RHQ side that we could then use as input into the above discussion.