JBMICROCONT-181 & ManagedDeployments

[starksm64]

I just checked in the current direction I'm heading in terms of updating the contract for deployer layer in terms of management views. The top level management view is a ManagedDeployment containing ManagedComponents. The role of the existing ManagedObject is not explicit in these views. Its more of an implementation detail around ManagedPropertys being connected to a DeploymentUnit metadata attachment instance. The existing DeployerClient.getManagedObjects methods should be dropped in favor of the new DeployerClient.getManagedDeployment method.

Likewise, the ManagedObjectCreator should be dropped in favor of the ManagedDeploymentCreator/ManagedComponentCreator interfaces. What I'm currently doing is working through the use cases the existing ProfileServiceUnitTestCase has as well as the "TODO JBMICROCONT-181 Critique" comment Adrian has in the ManagedObjectCreator.

I believe that we will have a standard ManagedDeploymentCreator implementation that uses the org.jboss.managed.api.annotation.* annotations to build the ManagedDeployment/ManagedComponent instances by parsing the DeploymentUnit attachments to identify what makes up the management interface. I also see that this could be augmented by deployers providing ManagedComponentCreators to deal with component properties that cannot adequately be described via annotations.

Right now I'm working on creating a DeployerManagedDeploymentUnitTestCase that illustrates the logic for a datasource(s) type of deployment. Let me know if there is a big disconnect with the api I checked in and this direction.

[adrian.brock]

Sounds reasonable, except the dropping of the ManagedObject.

The ManagedObject is meant to behave like an MBean, both for a
deployment descriptor as a whole but more convienantly for the lowest
unit of management (what I think you call components).

I also argued that you should be able to use it for smaller parts of the
deployment descriptor but that's irrelevant to this discussion, I think?

The way I originally thought it would work was that a -ds.xml
would really be little more than a collection of managed objects
and the MCF deployer work be just to create ManagedObjects for individual
datasources and connection factories (I know there's other things that can
go in a -ds.xml, e.g. mbeans - these would be other managed objects in the collection).

The top level managed object would know how to "reconstruct" the -ds.xml
from the individual pieces, or preferably the lower managed objects
would know where they fit in the whole.

The ejb deployer would be similar with a collection of EJB managed objects
and seperate one for the "deployment level" stuff.

The idea being it is pretty easy for the deployer writers to create ManagedObjects
(around their deployment descriptors - or more correctly parts of them)
if we add the framework that knows how to present the descriptors (and update them)
from annotations or xml) - we're really just wrapping their annotated metadata
which they've told us how to map.

This looks very similar to your ManagedComponent but it doesn't have
the notion of getting the attachment back again for the top level managed object
(the whole deployment descriptor) so it can set it in the "predetermined managed objects" for (re)deployment.

Where the disconnect occurs (to me) is there is no idea of top level managed object
(or top level managed component if you like) at all.

The only aggregate is the ManagedDeployment. But the deployer writers don't
(and shouldn't) care about this. e.g. The ejb deployer doesn't care if there is
also a META-INF/log4j.xml in an ejb jar, its irrelevant and orthogonal.

In summary:
I think ManagedComponent is really just a ManagedObject
under a different name and with extra information.
But it no longer serves the original purpose intended, i.e. of dealing with
management at the "atomic level" but also knowing where/how it fits in the
"bigger picture".

[adrian.brock]

Let me give you a more complicated example. So you can see more clearly
what I'm talking about and where I was heading (although not all of it was planned
for JBoss-5.0.0 :-)

The example is transaction attributes on ejbs.
These aren't configured in a very nice way (unless you use annotations).
You don't configure them directly on the ejb, you configure them in a seperate
section of ejb-jar.xml (that's because some of them can be wildcards).

I would expect the EJB managed object to have
a managed object that represents its business interface. It would really be a
collection of methods and part of it would be the transaction attribute.

The business interface managed object would also have a seperate
managed object to represent the "*" method (the wildcard).

These would know how to put the config changes back into the transaction assembly
part of the xml (assuming you wanted to get ejb-jar.xml back again).

Eventually I would expect us to add features to make this management
easier and more transparent:
(These are a lot more complicated ManagedObjects and I wasn't planning
on implementing these features in the initial release.)

1) The metadata knows whether "*" applies to its specific method.
But there should be some way to say it is actually using the "*" managed object
and linked to where it is really defined.

2) The "*" metadata should be able to know where it applies and show
what methods will change if it changes. Again these are links.

3) It should be possible to create alternate views of this information
(again ManagedObjects within the top level managed object that is really
just linking). e.g. a view that looks like the transaction-assembly and a view
that has it all unwrapped, i.e. one method - one attribute

Of course, this has all got to be described in a generic way such
that an admin console can understand it and present it to the user.

e.g. The view managed objects in (3) would have to be marked in some way
and probably assigned a "view group" so the admin console and
user knows what the alternate views are.

e.g.2 The links described above would need to be marked so it is obvious to the
console/user that the information shown (for convience) is actually coming
from somewhere else and they can navigate to where it is really defined.

As you can see, my view of a ManagedObject is not a simple one.
It represents a piece of metadata (not necessarily the whole metadata)
that knows where it fits in the whole model.
It also may not be the only ManagedObject presenting that piece of metadata.

[starksm64]

The top level managed object would know how to "reconstruct" the -ds.xml
from the individual pieces, or preferably the lower managed objects
would know where they fit in the whole.

The ejb deployer would be similar with a collection of EJB managed objects
and seperate one for the "deployment level" stuff.

The idea being it is pretty easy for the deployer writers to create ManagedObjects
(around their deployment descriptors - or more correctly parts of them)
if we add the framework that knows how to present the descriptors (and update them)
from annotations or xml) - we're really just wrapping their annotated metadata
which they've told us how to map.

Its not that the ManagedObject is gone, its just not manifest to the user from the aggregate ManagedDeployment and associated ManagedComponents. It still exists in terms of the metadata instance attachment. A ManagedComponent is a collection of ManagedPropertys that may have more than one ManagedObject depending on how many attachments make up the ManagedComponent.

This looks very similar to your ManagedComponent but it doesn't have
the notion of getting the attachment back again for the top level managed object
(the whole deployment descriptor) so it can set it in the "predetermined managed objects" for (re)deployment.

The attachment(s) for a given ManagedComponent is associated with the ManagedObject(s) that make up the ManagedComponent ManagedPropertys. I am looking at an ejb/datasource as the external component view an admin tool wants to work with being built up from multiple metadata attachments from the various deployers/descriptors that contribute ManagedPropertys to the component management view.

Where the disconnect occurs (to me) is there is no idea of top level managed object
(or top level managed component if you like) at all.

The only aggregate is the ManagedDeployment. But the deployer writers don't
(and shouldn't) care about this. e.g. The ejb deployer doesn't care if there is
also a META-INF/log4j.xml in an ejb jar, its irrelevant and orthogonal.

I do view the ManagedDeployment as the top level managed object. It will contain objects extraneous to an ejb deployer just as the DeploymentUnit contains attachments the ejb deployer does not care about. Maybe there does need to be a top level component that does better correspond to the jsr88 DeploymentConfiguration for example. I was not viewing the deployment descriptors as anything more than a serialized view of the attachment metadata, but maybe there needs to be a stronger coupling due to jsr88 keeping the xml oriented model.

[starksm64]

The business interface managed object would also have a seperate
managed object to represent the "*" method (the wildcard).
...
1) The metadata knows whether "*" applies to its specific method.
But there should be some way to say it is actually using the "*" managed object
and linked to where it is really defined.

2) The "*" metadata should be able to know where it applies and show
what methods will change if it changes. Again these are links.

I don't view the "*" notation as anything other than a convience for the selection of all methods on the ejb. I don't see that we need to be able to output the same shorthand descriptor. If a descriptor with wildcard mappings is parsed, the resulting metadata is just the collection of methods with the transaction and security attributes the wildcard is associated with mapped onto the methods. If this is serialized back to a descriptor, I don't see a need to be able to collapse the transaction or security assembly sections into a minimal wildcard form.

3) It should be possible to create alternate views of this information
(again ManagedObjects within the top level managed object that is really
just linking). e.g. a view that looks like the transaction-assembly and a view
that has it all unwrapped, i.e. one method - one attribute

Of course, this has all got to be described in a generic way such
that an admin console can understand it and present it to the user.

e.g. The view managed objects in (3) would have to be marked in some way
and probably assigned a "view group" so the admin console and
user knows what the alternate views are.

e.g.2 The links described above would need to be marked so it is obvious to the
console/user that the information shown (for convience) is actually coming
from somewhere else and they can navigate to where it is really defined.

As you can see, my view of a ManagedObject is not a simple one.
It represents a piece of metadata (not necessarily the whole metadata)
that knows where it fits in the whole model.
It also may not be the only ManagedObject presenting that piece of metadata.

I agree with the notion of views, but this seems more of an admin tool task rather than something the managed objects need to describe themselves. There does need to be an ability to link a ManagedProperty from one ManagedObject/ManagedComponent to another. I added a ManagementComponentRef annotation to allow the deployer writer to describe such relationships.

[adrian.brock]

I agree with the notion of views, but this seems more of an admin tool task.

But doesn't that defeat the whole purpose of the Managed project?

The admin console could do everything, but expecting it to keep in step
with changes is almost certainly a futile hope.

Only if the admin console is able to react to new metadata (or old metadata
for that matter) will the project have any hope of staying relevant.

The task is equivalent in scope/work to updating the doco everytime
somebody adds/changes configuration options.
In practice, if it is done at all, it is usually late and then misleading for users
of older versions.

[starksm64]

I agree with the notion of views, but this seems more of an admin tool task.

But doesn't that defeat the whole purpose of the Managed project?

The admin console could do everything, but expecting it to keep in step
with changes is almost certainly a futile hope.

Only if the admin console is able to react to new metadata (or old metadata
for that matter) will the project have any hope of staying relevant.

The task is equivalent in scope/work to updating the doco everytime
somebody adds/changes configuration options.
In practice, if it is done at all, it is usually late and then misleading for users
of older versions.

I see a view as a presentation option to the admin user. The purpose of the managed project is to expose the managed properties/ops for tools. Presenting those to the admin in a way they understand is the tools job. Even if we did provide hints for groupings, I still see the tools wanting to display these in their specific ways and as components have new managed features they will want to update their views.

[adrian.brock]

We'll have to agree to differ then. ;-)

P.S. I was planning on writing my own Swing admin console that was entirely
driven by the hints in the ManagedObjects. It might not be pretty, but it will
test whether the information/model can be used to construct "reasonable" UI
for user written deployers whose metadata model we know nothing about.

[ccrouch]

I see a view as a presentation option to the admin user. The purpose of the managed project is to expose the managed properties/ops for tools. Presenting those to the admin in a way they understand is the tools job. Even if we did provide hints for groupings, I still see the tools wanting to display these in their specific ways and as components have new managed features they will want to update their views.

+1.
There is no expectation that the UI of an admin console be dynamically rendered from metadata delivered by the management api. It is the responsibility of a console and its metadata to define how the data is ultimately presented. Support for versioning within a console could handle changes to the underlying management metadata.

But doesn't that defeat the whole purpose of the Managed project?

The admin console could do everything, but expecting it to keep in step
with changes is almost certainly a futile hope.

Only if the admin console is able to react to new metadata (or old metadata
for that matter) will the project have any hope of staying relevant.

The task is equivalent in scope/work to updating the doco everytime
somebody adds/changes configuration options.
In practice, if it is done at all, it is usually late and then misleading for users
of older versions.

-1
Tests for the management view of a component should be included in the testsuite and run as part of the build. The management view of a component should be considered as part of its public API. If it changes in an incompatible way, then tests should fail and dependent clients need to be updated.

Thanks

[adrian.brock]

-1
Tests for the management view of a component should be included in the testsuite and run as part of the build. The management view of a component should be considered as part of its public API. If it changes in an incompatible way, then tests should fail and dependent clients need to be updated.

Thanks

That policy (if I understand it correctly) will never scale and I won't subscribe to it.

If such a policy were implemented developers would simply take the easy approach
and never change the managed object view when their features evolve leaving
the admin console and profile service both out-dated and potentially incorrect.

It's hard enough getting people to keep dtds, schemas, WIKI/docs up-to-date.

If they can't innvocate around the management views they provide they'll simply ignore it.

However, at a different level I agree with you.

Obviously the underlying metdata model should not change
in an incompatible way otherwise profiles from one version won't load
in a later version. Similarly it should be possible to take profiles edited in
a later version and load them in earlier versions (provided the user
has deliberately not used a feature from the later version).

[adrian.brock]

If they can't innvocate around the management views they provide they'll simply ignore it.

Take an example from JCA. If you wanted the database failover you've previously
had to use

ha-local-tx-data-source

this is because we consider
it experimental and didn't want to upset the main jdbc rar.

Now its been in the wild and tested, those features are now being rolled into the standard datasource configuration.

Are you saying we can't do this?

Of course, it needs an annotation that says

@From("jboss-5.0.0")
@ManagedProperty("url-delimiter")
public void setURLDeliimeter(String delimeter) {};

so we can warn the user in case they want to use the profile on an earlier version
than this.

[adrian.brock]

If they can't innvocate around the management views they provide they'll simply ignore it.

They might like to innovate as well. ;-)

I've been looking at AOP code too much recently!

[starksm64]

We'll have to agree to differ then. ;-)

P.S. I was planning on writing my own Swing admin console that was entirely
driven by the hints in the ManagedObjects. It might not be pretty, but it will
test whether the information/model can be used to construct "reasonable" UI
for user written deployers whose metadata model we know nothing about.

I don't know that I so much disagree as don't want to get too hung up on making this a required feature initially. Certainly in principle the default jmx console could use this to generate a much better default view of the admin capabilities. Its just not a required feature in order for an admin tool to be able to effectively manage a server.

I guess the main issue is validating that there are not incompatible evolutions of existing properties, as well as making sure that new properties that need user attention have some support without the tool needing a complete revision. For the ha datasource URLDeliimeter property, its is a new datasource type that does effectively need some synchronization with the admin tool as there can be a lot of hidden complexity in the list of jdbc urls in terms of a tool providing testing to ping the indicated databases. Arguably this also requires a new multi-valued jdbc url property rather than a separator that is used in combination with the old jdbc url. How we deal with this type of evolution best is the question.

[starksm64]

I'm looking at reusing the existing ManagedObjectFactory, ManagedObjectBuilder, ManagedObjectPopulator classes as the bases for the ManagedDeployment/ManagedComponent. I am thinking the latter are just extensions of ManagedObject now with the aggregate notion and component notion added.

A couple of issues:

1) The AbstractManagedObjectFactory.buildManagedObject(Class) method always produces a ManagedObject. If an attachment class does not have a ManagementObject annotation I don't think we should as a loop over all DeploymentUnit attachments is going to have too many ManagementObjects.

2) We can't adequately describe the ManagedProperty constraints (allowed values, min/max) via annotations. It seems we need something like a ManagedPropertyConstraintsPopulator:

interface ManagedPropertyConstraintsPopulator
{
 /** Populate the ManagedProperty fields constraint related info
 */
 populateManagedProperty(Class attachmentClass, PropertyInfo info, Fields fields);
}

and this would be registered with the ManagedObjectFactory similar to how ManagedObjectBuilders are.

[adrian.brock]

For the ha datasource URLDeliimeter property, its is a new datasource type that does effectively need some synchronization with the admin tool as there can be a lot of hidden complexity in the list of jdbc urls in terms of a tool providing testing to ping the indicated databases. Arguably this also requires a new multi-valued jdbc url property rather than a separator that is used in combination with the old jdbc url. How we deal with this type of evolution best is the question.

That's exacly my point. The underlying model is a connection-url and a delimiter.
It has to be that way because it is configuring an MCF which can only take strings
and primitives as parameters.

We could at some future time decide that really this should be a exposed as
one mangaged property that is an array or list.

The underlying model doesn't change, but what appears in the management
layer (and to the user) is easier to understand.