----- Original Message -----
From: "Elias Ross" <genman(a)noderunner.net>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Wednesday, July 24, 2013 5:15:11 PM
Subject: Re: How about an annotation processor to create "glue code" and
descriptor to convert your code into RHQ plugin?
On Tue, Jul 23, 2013 at 5:00 AM, Lukas Krejci < lkrejci(a)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.
I think keeping the annotations at runtime and making use of them to "establish"
the pugin instead of just parsing the plugin descriptor in the agent and server has the
below problems that I just can't decide how severe they are:
* Time and memory required to parse the plugin jar at start up (can be helped by jandex
and/or persisting the results in agent "cache") - although this can't be
worse than JAXB that we use now ;)
* Currently we don't have to load the classes of the plugin jar on the server to get
the resource type defs contained within - this'd have to change
* You leave the detection of the problems in the annotation definitions to the run-time.
When using the annotation processor, these can be detected at compile-time.
I agree that CDI would be very nice but I am, too, afraid of the memory consumption. We
have enough performance and memory consumption problems in the agent that I don't want
to make that situation worse. But even if it wasn't full CDI, we could think about
some basic injection support. Your snippet is a perfect example of what we could do.
@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.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel