JBoss Forge plugin would nice but I think it is somewhat unrelated to the original idea.
JBoss Forge is a tool for automatic code generation - you either start from scratch or
hand it a piece of code (a jar) that it will grok and it will help you add new
functionality into your code.
I.e. on the Forge commandline you'd be able to do things like:
$ rhq add --metric --named "Foo" --required="true"
--dataType="int"
This would go into the code, add stuff into the plugin descriptor, make sure your code
implements correct interfaces and maybe even stub out the impl of the metric collection
for you.
But that is completely different from what I originally had in mind.
My idea was that the users would be able to define a complete plugin by ONLY annotating
their Pojos with RHQ-specific annotations. Our annotation processor would then - at
compile time - generate necessary glue code and plugin descriptor to turn that bunch of
POJOs into a fully functional plugin.
So, in the case of Forge, you'd use Forge's commandline to modify code that would
otherwise be your old-fashioned RHQ plugin. It'd have the plugin descriptor in
META-INF, the classes would implement our facets, etc. With the annotation processor
approach, none of that would be true. The code would (ideally) contain no RHQ specific
APIs apart from the annotations (unfortunately I am quite sure that goal won't be
achieved for events and content):
@PojoResourceComponent
public class MyComponent {
private MyConnectionConfiguration pluginConfig;
public MyComponent(MyConnectionConfiguration pluginConfig) {
this.pluginConfig = pluginConfig;
}
@Metric
public int getNumberOfSomething() {
...
}
@ResourceConfiguration
public MyConfiguration readTheConfigFromTheManagedResource() {
...
}
@ResourceConfiguration
public void updateTheConfigInTheManagedResource(MyConfiguration newConfig) {
...
}
}
public class MyConnectionConfiguration {
@Required
private String installPath;
@Default("true")
@Required
private boolean makeItSimple;
private List<String> flags;
public String getInstallPath() {
return installPath;
}
public void setInstallPath(String value) {
installPath = value;
}
public boolean isMakeItSimple() {
return makeItSimple;
}
public void setMakeItSimple(boolean value) {
makeItSimple = value;
}
public List<String> getFlags() {
return flags;
}
public void setFlags(List<String> value) {
this.flags = value;
}
}
public class MyConfiguration {
public enum LogLevel {
DEBUG, INFO, WARN, ERROR, FATAL
}
@Property(description = "The log level that the managed resource outputs its
messages to the log files.")
private LogLevel logLevel;
public LogLevel getLogLevel() {
return logLevel;
}
public void setLogLevel(LogLevel value) {
logLevel = value;
}
}
That is a complete definition of a plugin component (without discovery) together with a
complex plugin and resource config and 1 metric. Defining the plugin like this has, IMHO,
at least 2 advantages:
1) no XML (even though considering that an advantage is debatable ;) )
2) type-safe configuration objects
Upon compiling these classes with our annotation processor on the classpath, the resulting
JAR would have a plugin descriptor generated from the sources and a couple of new,
generated, classes that would implement the "normal" RHQ facets, etc and call
out to the above defined POJOs in appropriate places.
----- Original Message -----
From: "John Sanda" <jsanda(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Friday, July 19, 2013 8:34:12 PM
Subject: Re: How about an annotation processor to create "glue code" and
descriptor to convert your code into RHQ plugin?
On Jul 19, 2013, at 1:49 PM, Lukas Krejci < lkrejci(a)redhat.com
> wrote:
> I think that idea is worth exploring, but I wanted to put it out
there very
> soon to see if others share my view :)
> I went ahead and started designing the annotations, so if you
feel like you
> are interested and would like to shape the future of RHQ, please chime in
> to
> Note that I originally based this work on what has already been
done in the
> helpers/pluginAnnotations module of RHQ but I decided to split it off into
> a
> completely separate repository because this needs to go through some
> serious
> design and prototyping before it can become part of the official codebase
> of
> RHQ.
I am only a little familiar with JBoss Forge[1] but would it be
worth
exploring the possibility of implementing this as a Forge plugin?
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel