My view of this was that one had to define the ManagedPropertys that exist on the attachments making up the parsed DeploymentUnit, and these would make up the DeploymentUnit ManagedObject. What is missing in your version of the ManagedProperty that I had in the ManagedPropertyRef was a notion of a context that allowed for classification of the ManagedPropertys into subsets. For example, just the DataSource/URL or DataSource/Pool set of properties.
The requirement for a split view you mention is what is problematic, and I'm not sure its needed. That multiple deployment descriptors can affect a given attachment metadata property is something that may need to be audited, but I don't see that these need to be kept as distinct changes. If I have a deployment whose parsed DeploymentUnit metadata attachments produce an ejb property x, the deployment level setting that produced x is only relevant for debugging. As a queriable aspect of the management api its a cumbersome starting requirement. If we want to get such a thing, we would have to have a property change event notion that has sufficient info to tie into the property mapping api to allow this to be determined.
The version of ManagedProperty that I have is just a wrapper for
arbitrary Fields (like a JMX descriptor).
It would clearly be trivial to add a Fields.CONTEXT as a standard one.
The plan is that the additional fields will really be annotations on the metadata classes,
making them trivial to maintain and easy to keep up-to-date.
There are a number of reasons for keeping the metadata/underlyingManagedObjects
seperate for the different attachments (e.g. ejb-jar, jboss.xml), while still providing
a unifying ManagedObject for ease use.
The most important is that you can marshall them back into the xml from the attachments.
Once you've merged them into a single view, this is not in general possible.
Another is that an admin console can "follow the links" to navigate through
complex models, e.g. following an ejb-link to the target ejb.