custom plugin configuration

John Mazzitelli mazz at redhat.com
Mon Apr 25 17:55:32 UTC 2011



On 04/25/2011 12:55 PM, Bala Nair wrote:
 > Ok, so if I understand this, simple properties are data when children 
 > of plugin configuration, but metadata when children of configuration 
 > properties?

Actually, that's not true either. All these XML elements 
(simple-property, list-property, map-property) are metadata definitions. 
However, the "default" *attribute* does set the data value which is used 
when RHQ wants to instantiate a property for which a value is not yet 
set. For example:

<simple-property name="port" default="8080" type="integer" />

This isn't data. This is defining an property named "port" whose type is 
"integer". It just so happens that anytime we want to display this or 
produce a default configuration that has this property in it, we'll use 
"8080" as its initial value. So its a semantic different I'm trying to 
point out - the "simple-property" isn't data, its a metadata definition 
- but its attribute "default" can be construed as data (but its only 
used when creating an initial configuration that contains this property 
and whose value isn't already set - such as in the UI for example).

We use the default attribute values when building the definition's 
"default template" which we then can create a default configuration. 
This is getting technical and is an implementation detail - but I am 
saying that the "simple-property" itself is the definition and must be 
treated as such.

 > Is it possible to create a list of simple properties that
 > I can iterate through in the code?

You might be able to do something like this if you really want to define 
a set of default values in the XML descriptor itself (I'm not keen on 
this myself, but if you reeeeally want this in the XML, it might be 
possible):

<plugin-configuration>
  <c:group name="myLogDefaults" hiddenByDefault="true">
   <c:simple-property name="log.1" default="name1.log" readOnly="true" />
   <c:simple-property name="log.2" default="name2.log" readOnly="true" />
  </c:group>
  ... and the rest of your plugin-config...
</plugin-configuration>

You can then use the API to get your plugin configuration normally and 
iterate all properties whose names match the pattern "log.#" - you 
iterate over them and use their values as you see fit. Since they have 
defaults, when the plugin is given its initial plugin configuration, 
those properties will have those values assigned to the "log1" property 
and "log2" property.

Side note: hiddenByDefault="true" is just so the section in the config 
editor UI is initially shown as collapsed for this group of properties - 
since they are really only for your plugin's use and the user doesn't 
care about them. They can still expand the section and see this values 
in the UI, but its no harm-no foul - the properties specify 
readOnly="true" so they can't change them.

In the end, I don't see why you'd want to do this or what this buys you. 
You can just as easily put this data in the server component class and 
not "dirty up" the plugin configuration definition with these log.# 
properties. If you want to customize your log files, the user can add or 
remove them from the list-of-maps property. Having them in the plugin 
configuration as I proposed above only does two things as I see it:

1) moves the hardcoding of the default values from Java code to XML 
(this is a good or bad thing depending on how you view XML)

2) allows the user to see the hardcoded default values in the UI even if 
they are no longer in the real list-of-maps (I'm not sure how much it 
would benefit users to see this).

In the end, its obviously up to you - you may have motivations and 
use-cases that really require this.


More information about the rhq-devel mailing list