[infinispan-dev] [ISPN-134] Creating @Jopr* annotations or extending @Managed* ones?

[Manik Surtani]

On 30 Sep 2009, at 12:42, Heiko W.Rupp wrote:

> Hi Galder,
>
> Am 30.09.2009 um 11:51 schrieb Galder Zamarreno:
>
>> two are measurement metrics, the two below are trait metrics. So, on
>> top
>> of jopr adding new fields, there's the issue that not all
>> @ManagedAttribute map to the same thing on the jopr side.
>
> Yes. This would e.g. need an attribute of "dataType"
>
>> So, my suggestion would be to have some jopr specific annotations  
>> that
>> allow us to differentiate between different jopr types (i.e.
>> @JoprMetric(dataType="measurement"), @JoprMetric(dataType="trait"))
>> and
>> where we can add any extra information required by jopr, i.e.
>> displayName...etc.
>>
>
> Good idea.
>
>> I think using this annotations would be cleaner than extending
>> @Managed*
>> ones. Also, such @Jopr* or annotations would need to live in core/
>>
>> Heiko, does Jopr have annotations like this already?
>
> No we don't
>
> Actually I'd love to see that within $RHQ/modules/helpers so that
> other projects
> can pick it up to define their plugin descriptors too.
> This could perhaps live in the plugin generator, where a phase after
> defining the properties of a server/service would be to ask the
> questions
> "shall I scan for annotations to create metrics" and then
> "please pass a package/classes mask for the classes to use". This
> would then go out, gather all that data and populate the <metric> tags
> along with "if (req.getName().equals("xxx") .. { " blocks in  
> getValues()
> Same could happen for some @RhqOperation and @RhqConfiguration (for
> resource configuration bits) too.

I'm all for this, as long as the annotations are packaged in a  
lightweight jar (jopr-client-annotations?) so that infinispan-core  
doesn't have deps on all of JOPR.  :-)

Cheers
Manik
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org