custom plugin configuration

Bala Nair bnairtm at comcast.net
Mon Apr 25 18:58:05 UTC 2011


The reason I want to do this is so I can create my own discovery and 
component classes that implement common behaviors and use those to 
create a variety of plugins for different services ala the jmx based 
custom plugins.  Jmx does this with the objectName and nameTemplate 
config properties that let the plugin author inject data into the 
plugin.  I want to do the same thing with log file names, but I wanted 
the number of logs and their names to be determined by the plugin 
authors.  Most of our services are similarly behaved but with different 
data.  I suppose I could just point to a configuration file and get my 
values from there, but that's another file to track in source control 
and builds and kitting...

Bala Nair

On 4/25/11 1:55 PM, John Mazzitelli wrote:
>
> 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.
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
>


More information about the rhq-devel mailing list