ManagedObjects of ManagedObjects, etc.

[adrian.brock]

Apologies in advance if this is a bit of a brain dump since I don't have
this clear in my head yet.

If you look at the OpenMBean api there is an OpenType, SimpleType.OBJECT_NAME
which is used to link MBeans together, i..e. to implement references.

Currently in the MetaType api I haven't added this.

The main use case for this is for ManagedObjects of ManagedObjects,
e.g. a ServiceDeployment has a LoaderRepositoryConfig and a List of ServiceMetaData
which need to be ManagedObjects in their own right.
This part is fairly trivial to implement.

What is not so trivial is when you get to more complicated deployments.
e.g. an ejb deployment can have multiple attachments (ejb-jar.xml, jboss.xml,
jbosscmp-jdbc.xml)

Additionally, the ejb deployment is made of multiple ejbs, each has the
same split, i.e. multiple attachments but they see the "sub managed objects"
of the main managed objects.

These are obviously references like the SimpleType.OBJECT_NAME.

There are also two views:
1) The merged view, i.e. I am managing this ejb
2) The split view, i.e. give me the updated attachments (plural) for this ejb
deployment

Finally, the keys to these references can be used elsewhere,
e.g. the ejb's assembly descriptor

What is not clear to me yet, is how we implement this such that:
* It is easy for the deployer to describe how these references work
(this element of jboss.xml is related to another element in ejb-jar.xml)
* It is easy for the profile service/admin console to understand/use these references
(e.g. providing a drop down list of available ejb-names when editiing the
assembly descriptor)

I think only going through the more complicated uses cases will reveal
all the issues, unless somebody has a clearer view than me on them?

[starksm64]

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.

[adrian.brock]

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.