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.