"charles.crouch@jboss.com" wrote:
So IIRC the idea was to create specific annotations representing common resources we want to manage, right?
Its attributes would be used to map from a known management attribute name (e.g. connectionURL) to an implementation specific property name.

....

If so, what are you meant to annotate using this? I thought from our discussions that it would be a subclass of Deployment but that really doesn't seem right now?

Yes, an example from what I'm working on:

@ManagedObject
@Retention(value=RetentionPolicy.RUNTIME)
public @interface DataSourceView
{
 public String jndiName() default "JndiName";
 public String useJavaContext() default "UseJavaContext";
 public String securityDomainJndiName() default "SecurityDomainJndiName";
 public String typeMapping() default "TypeMapping";
 public PoolView pool() default @PoolView;
}

@ManagedObject
@Retention(value=RetentionPolicy.RUNTIME)
public @interface PoolView
{
 public String minSize() default "MinSize";
 public String maxSize() default "MaxSize";
}

See the current Deployment interface which has a getManagedObject() accessor.

"charles.crouch@jboss.com" wrote:

In the above example "connectionURI" is the name of a property on a DeploymentBean?

From the diagram it looks like ManagementView.getView(blah) is going to return the ManagedObject annotation. What is a client of the ProfileService going to do with that?
ManagementView.getViewProperties(blah) will return a Map of PropertyInfo objects. Is this map keyed off the name of the DeploymentBean properties, e.g. "connectionURI"?

The ManagedObject instance itself only has meaning to the extent that the client understands it. For the case of a dynamic managment client like a new jmx-console, it would only conveny a sense of structure due to nested annotations (DataSourceView/PoolView). Otherwise it goes back to the bean developer/management tool developer interaction. The bean developer has to commit to a stable ManagedObject and the tool developer supports as rich an interface to editing this as needed. Now the problem with using an annotation for this is that its weak in terms of type info. No one knows that the type of useJavaContext is a boolean, and that the minSize is an int. I can get this from the ManagedView.getViewProperties HashMap<String, PropertyInfo>, but this leads to the next implementation problem of creating this map. This relates to the next question...

"charles.crouch@jboss.com" wrote:

The ManagedProperty annotations are to go on the underlying POJOs which actually implement the service, correct?

public class ConnectionManager {
 @ManagedProperty(use = ViewUse.CONFIGURATION)
 private String prop1;
}

public class ManagedConnectionFactory {
 @ManagedProperty(use = ViewUse.CONFIGURATION)
 private String prop2;
}

I'm not seeing how @ManagedProperty and @ManagedObject will tie together at runtime.

Yes, back to the weakness of the @ManagedObject representation, the flat namespace of the @ManagedObject attributes requires that some DeploymentBean has a MinSize property that matches the DataSourceView.pool().minSize(), another has a UseJavaContext property that matches the DataSourceView.useJavaContext(), etc. We could use a "BeanName.PropertyName" convention for the @ManagedObject attribute to DeploymentBean property mapping. I'm wondering if the @ManagedObject representation is really where we should be heading though.

An alternate approach to the @ManagedObject would be the following:

@Retention(value=RetentionPolicy.RUNTIME)
@Target(value= ElementType.ANNOTATION_TYPE)
public @interface ManagedObject
{
 ManagedPropertyRef[] properties() default {};
}

@Retention(value=RetentionPolicy.RUNTIME)
public @interface ManagedPropertyRef
{
 /**
 * A namespace context that maps the managed property onto a managed view
 * context (e.g., /, /DataSource, /DataSource/Pool).
 * @return
 */
 String context() default "/";
 /**
 * The DeploymentBean name which sources the property
 * @return
 */
 String beanName();
 /**
 * The DeploymentBean property name
 * @return
 */
 String propertyName();
 /**
 * An option management view description of the property
 * @return
 */
 String description() default "";
}

where the structure of the management view is folded into the ManagedPropertyRef context using a convention similar to JNDI naming. The type information and constraints still has to come from the DeploymentInfo PropertyInfo, but this mapping seems a bit clearer to me.

And now I'm down to not seeing any benefit to the ManagedObject being an annotation at all. The reason being that aggregate/structured annotations are just difficult to deal with unless they are well known. Instead I now just have it as a pojo with a mapping of the bean properties that make up the managment interface. One version is a direct mapping:

public class ManagedObject
{
 private ArrayList<PropertyInfo> properties = new ArrayList<PropertyInfo>();

 public List<PropertyInfo> getProperties()
 {
 return properties;
 }

 public boolean addPropertyRef(PropertyInfo ref)
 {
 return properties.add(ref);
 }
 public boolean removePropertyRef(PropertyInfo ref)
 {
 return properties.remove(ref);
 }
 public int getSize()
 {
 return properties.size();
 }
 public void clear()
 {
 properties.clear();
 }
}

Another version maintains a layer of indirection that allows for the management view via ManagedPropertyRef pojos:

public class ManagedObject
{
 private ArrayList<ManagedPropertyRef> properties = new ArrayList<ManagedPropertyRef>();

 public List<ManagedPropertyRef> getProperties()
 {
 return properties;
 }

 public boolean addPropertyRef(ManagedPropertyRef ref)
 {
 return properties.add(ref);
 }
 public boolean removePropertyRef(ManagedPropertyRef ref)
 {
 return properties.remove(ref);
 }
 public int getSize()
 {
 return properties.size();
 }
 public void clear()
 {
 properties.clear();
 }
}

public class ManagedPropertyRef
{
 /**
 * A namespace context that maps the managed property onto a managed view
 * context (e.g., /, /DataSource, /DataSource/Pool).
 */
 private String context;
 /**
 * The DeploymentBean name which sources the property
 * @return
 */
 private String beanName;
 /**
 * The DeploymentBean property name
 */
 private String propertyName;
 /**
 * An option management view description of the property
 */
 private String description;

 /**
 * Create a managed property ref for the indicated bean property.
 * @param context
 * @param beanName
 * @param propertyName
 * @param description
 */
 public ManagedPropertyRef(String context, String beanName,
 String propertyName, String description)
 {
 this.context = context;
 this.beanName = beanName;
 this.propertyName = propertyName;
 this.description = description;
 }

 /**
 * @return Returns the beanName.
 */
 public String getBeanName()
 {
 return this.beanName;
 }

 /**
 * @return Returns the context.
 */
 public String getContext()
 {
 return this.context;
 }

 /**
 * @return Returns the description.
 */
 public String getDescription()
 {
 return this.description;
 }

 /**
 * @return Returns the propertyName.
 */
 public String getPropertyName()
 {
 return this.propertyName;
 }

 /**
 * Equality based on beanName + propertyName
 */
 public boolean equals(Object obj)
 {
 ManagedPropertyRef ref = (ManagedPropertyRef) obj;
 boolean equals = beanName.equals(ref.beanName);
 if( equals )
 {
 equals = propertyName.equals(ref.propertyName);
 }
 return equals;
 }

 /**
 * Hash based on beanName + propertyName
 */
 public int hashCode()
 {
 return beanName.hashCode() + propertyName.hashCode();
 }
}

Both of these could be built from the DeploymentBean PropertyInfo objects if they were marked up with a ManagedProperty annotation that provided the additional management view context.