[adrian.brock]

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.

Ok, that's probably just a mistake because the code is incomplete?

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

I think we can in most cases, but when we can't your idea looks a good one.
Just as long as it isn't an all or nothing. i.e. you can use it to override
just one property where the annotations are currently inadequete
rather than having to recode everything.

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.

[ccrouch]

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.

Thats a better way to put it Scott. Its not that its a bad thing to care about, there are just lots more important things to care about instead.

Adrian, I wasn't arguing against innovation in the management layer as defined by the developer. It would be the responsibility of whoever maintained the console to make sure any integration layer with the app server's manageable components stayed in sync.

I agree that assuming core dev's will maintain a separate management piece, external to their own annotations etc, is unrealistic. However I believe its equally unlikely that developers would want/be able to provide sufficient metadata to enable any dynamically driven management and administration console to have sufficient usability. It would more likely boil down to a lowest common denominator, much like the current jmx-console.

[starksm64]

I think we can in most cases, but when we can't your idea looks a good one.
Just as long as it isn't an all or nothing. i.e. you can use it to override
just one property where the annotations are currently inadequete
rather than having to recode everything.

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

If we also define a ManagedPropertyConstraintsPopulatorFactory, then we can introduce a constraintsFactory field to the ManagementProperty annotation to simplify the registration of the supplier.