Description of problem:
Consider the following scenario. We have an old version of a plugin and a bunch of resources in the inventory that have a resource type coming from that plugin.

Now a new version of the plugin comes in, where the resource type in question defines some new required properties. These properties are assigned values during (auto)discovery.

But what happens when the server upgrades the plugin? The required properties are required to have the default values (which are hardcoded in the plugin descriptor) and the server uses these default values to populate the plugin/resource configurations of the resources that existed before the plugin upgrade.

But what that means? The default values will most possibly be just a non-sensical placeholder, because a sensible value can only be determined by running the discovery code. Therefore the "old" resources will have to be manually visited by the RHQ users and the new required properties manually updated to have values that would otherwise be automagically provided.

How reproducible:
always

Steps to Reproduce:
1. Install RHQ 1.3.x, inventory an Apache server
2. Upgrade to RHQ 4, keeping the database

  
Actual results:
DocumentRoot and other properties in the resource/plugin configuration of the inventoried apache server are going to have placeholder values.

Expected results:
These values are perfectly auto-detectable using the discovery code, so ideally the upgrade of an existing resource should have the possibility to assign a meaningful value to these props.

Additional info:
The only thing we need to consider here is the core principle of RHQ, that the server is the ultimate source of the configuration. By allowing the plugins to change the configurations one would think we would be breaking that principle.
In my opinion that is not entirely true. When the plugin would try to upgrade the plugin/resource configuration, it would do it for very specific reasons - namely to allow the resource to function with the new version of the plugin, which can potentially require a) new required properties, b) different format of existing properties, c) rename some properties, etc. 
All these scenarios are easily imaginable but are impossible to handle without tedious user intervention (tedious = read the manual of the plugin and figure out what values should be entered where by examining the configuration of the underlying managed resource).
Even if we decided not to let the plugins upgrade the "whole" configurations, they still *should* have the possibility to provide runtime-detected defaults to the new properties - the user did not have a chance to provide a value to those yet.