Description of problem: When a plugin is upgraded and a resource defined in the plugin introduces new connection properties as follows, <plugin> ... <server name="My Server"> <plugin-configuration> <!-- This is a new connection property --> <c:simple-property name="test1" default="Test One" required="true"/> </plugin-configuration> </server> ... </plugin> the new connection property is added to the resource type's plugin configuration. For existing resources of that type, that new connection is set to the default value declared in the plugin descriptor. See bug 573034 for more information about the work done around this. If the new version of the plugin includes a connection property that is either completely new and part of a new group or was previously an ungrouped property and is now part of an existing group, the property does not get set to its default value for existing resources of that particular resource type. Here are a couple examples to illustrate the problem. <plugin> ... <server name="My Server"> <plugin-configuration> <!-- This is a new group. It did not exist in previous versions of the plugin. --> <c:group name="Test Properties"> <!-- This is a new connection property --> <c:simple-property name="test2" default="Test Two" required="true"/> </plugin-configuration> </server> ... </plugin> In this example, we have added a new group named 'Test Properties' to the plugin configuration. The group includes a new property named 'test2'. test2 will be added to the plugin configurations of existing resources; however, it is not set to its default value. In the next example we look an existing property that was not part of any group, and in the new version of the plugin is now part of some group. <plugin> ... <server name="My Server"> <plugin-configuration> <!-- This is an existing group. It did exist in previous versions of the plugin. --> <c:group name="Test Properties"> <!-- test3 previously existed in the plugin configuration outside of any group. Before it was not required and did not specify a default value. Now it is part of the Test Properties group and is required and specifies a default value. --> <c:simple-property name="test3" default="Test Three" required="true"/> </plugin-configuration> </server> ... </plugin> In this example, the test3 property existed a previous version of the plugin, but now it is part of the Test Properties group. In this case like in the previous one, the property will be found in plugin configurations of existing resources; however, the property is not set to its default value. Note that in this case, the property should only be set to its default value if it was previously unset. This issue manifests itself in the jboss-as and apache plugins. See bug 573034 and bug 619248 for history on this issue. There may be other scenarios in the plugin descriptor that are affected by this issue. The two described above are ones that have already been reproduced in testing. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
jsanda - do you think this is a blocker for jon/rhq release?
Adding a new connection property to an existing group does appear to work. I see it in the UI with the default value set.
I observed the following during some manual testing. * A connection property is declared in a group in version 1 of the plugin. The property is neither required nor specified a default * In version 2 of the plugin I move the property outside of the group, make it required, and specify a default value. * After the plugin is upgraded, existing resources do not have the default value applied to the property. * In the UI, the property still appears in the group
Some more observations. When a property previously existed outside of any group and then is added to a group, the plugin upgrade code does not add the property to the group.
I updated code in ResourceMetadataManagerBean and in ConfigurationMetadataManager to handle the cases described in the initial description. commit hash: f0fffb5636ef2cdf89f6a1a1b1808e5d2fd98b6c Here are the following scenarios of which I am aware that need to be tested. In each of these scenarios, it can be assumed that the property mentioned has its required flag set to true and that a default value is specified as illustrated in the examples in the initial description. 1) New, ungrouped property 2) Existing, ungrouped property changed to be required and specify a default value. Note that in this case, we only want to set the default if it has a value of null currently. 3) New property added to a new group 4) Existing, ungrouped property changed to required with default value and added to a new group 5) Existing, ungrouped property changed to required with default value and added to an existing group 6) New property added to existing group 7) Existing property in existing group moved outside of group and changed to required with default value
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.