ManagementView changes

[ccrouch]

Initial changes/questions...

1) Update org.jboss.deployers.spi.management.ManagementView to use
org.jboss.managed.api.ManagedObject

not
org.jboss.deployers.spi.management.ManagedObject
nor
org.jboss.annotation.management.ManagedObject

To do this we need a new release or snapshot of the Microcontainer right? So we can get the jboss-managed.jar (http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/managed/) into /thirdparty/jboss/microcontainer/lib.

Since /trunk is currently using the MC Beta from November:

Implementation-Version: 2.0.0.Beta (build: SVNTag=https://svn.jboss.org/repos/jbossas/projects/microcontainer/tags/JBossMC_2_0_0_Beta date= 200611172149)

I guess we need a Beta2?


2) Currently the only method on ManagementView is

public ManagedObject getView(ProfileKey key, String deploymentName, String version)
 throws NoSuchProfileException, NoSuchDeploymentException;

What does the version argument correspond to here?


3) I see two stubbed implementations of ManagementView, they also include this method:

public void setView(ProfileKey key, String deploymentName, HashMap<String, PropertyInfo> view)
 throws NoSuchProfileException, IOException

I think this should be changed to be

public void setView(ProfileKey key, String deploymentName, ManagedObject view)
 throws NoSuchProfileException, IOException

and put into the ManagementView interface.


4) We need the concept of a deployment type in order to support retrieving all ManagedObject's/deploymentName's of a particular type e.g. DataSource

either

public List<ManagedObject> getViews(ProfileKey key, DeploymentType deploy)
 throws NoSuchProfileException, IOException

or

public List<String> getDeploymentNames(ProfileKey key, DeploymentType deploy)
 throws NoSuchProfileException, IOException

5) If we're going to have deploymentName in the API for getView() and setView() then ManagedObject needs to be updated to support accessing the associated deploymentName, otherwise if we've got a list of ManagedObjects and we want to update one of them then we're not going to know what to pass into setView()


6) I didn't want to muddy the waters further but clearly we're going to need some concept of setView() representing new deployments, and also removeView() to undeploy/delete existing deployments. I figure we can get to those later, once we've got further on the Read/List api.

Thanks

[starksm64]

Initial changes/questions...

1) Update org.jboss.deployers.spi.management.ManagementView to use
org.jboss.managed.api.ManagedObject
...

I guess we need a Beta2?

We have to decouple the elements of the mc as used by jbossas to allow for finer grained artifacts. There should be a jboss-managed snapshot.

[starksm64]

2) Currently the only method on ManagementView is

public ManagedObject getView(ProfileKey key, String deploymentName, String version)
 throws NoSuchProfileException, NoSuchDeploymentException;

What does the version argument correspond to here?

The version of the managed object view for the deployment. There are two version levels currently, the profile version which defines what deployments are in the profile, and the managed object view which defines the admin changes that have been applied. There is not a global version notion ala svn. The profile version changes when deployments are added/removed. The deployment managed object version changes as admin edits are applied.

[starksm64]

3) I see two stubbed implementations of ManagementView, they also include this method:

public void setView(ProfileKey key, String deploymentName, HashMap<String, PropertyInfo> view)
 throws NoSuchProfileException, IOException

I think this should be changed to be

public void setView(ProfileKey key, String deploymentName, ManagedObject view)
 throws NoSuchProfileException, IOException

and put into the ManagementView interface.

Until we drill into the ManagedObject to attachment metadata property/bean propertymapping I'm not sure the current view notion is adequate. The complexity of the ManagedObject as returned from an ear vs a data source is essentially unbounded. As a collection of changes the profile service saves off its ok, but how tools edit this needs expanding. Certainly related to 4.

[starksm64]

4) We need the concept of a deployment type in order to support retrieving all ManagedObject's/deploymentName's of a particular type e.g. DataSource

either

public List<ManagedObject> getViews(ProfileKey key, DeploymentType deploy)
 throws NoSuchProfileException, IOException

or

public List<String> getDeploymentNames(ProfileKey key, DeploymentType deploy)
 throws NoSuchProfileException, IOException

I think we need to flesh out the ManagedObject to deployment metadata mapping issue to define this. The ManagedPropertyRef I had previously dealt with the notion of a collection of properties using the context notion:

public class ManagedPropertyRef
{
 /**
 * A namespace context that maps the managed property onto a managed view
 * context (e.g., /, /DataSource, /DataSource/Pool).
 */
 private String context;

Part of the property mapping definition should be a classification of the property from the perspective of an admin tool. In reality a property may be in multiple view/perspectives if we start talking about view likes "Server Ports", "Clustering", "Network Interfaces".

[starksm64]

6) I didn't want to muddy the waters further but clearly we're going to need some concept of setView() representing new deployments, and also removeView() to undeploy/delete existing deployments. I figure we can get to those later, once we've got further on the Read/List api.

The management of the deployments in a profile is part of the Profile interface, not a ManagedObject notion.

[ccrouch]

The management of the deployments in a profile is part of the Profile interface, not a ManagedObject notion.

Ok, understood.

[ccrouch]

The ManagedPropertyRef I had previously dealt with the notion of a collection of properties using the context notion:

/**
 * A namespace context that maps the managed property onto a managed view
 * context (e.g., /, /DataSource, /DataSource/Pool).
 */

Part of the property mapping definition should be a classification of the property from the perspective of an admin tool. In reality a property may be in multiple view/perspectives if we start talking about view likes "Server Ports", "Clustering", "Network Interfaces".

I'm not sure I fully understand this. Take for example two properties on a DataSource: the jndiName, and maxConnectionPoolSize. Would both of these properties get mapped to the /DataSource context?
Say I had two datasources deployed A and B, and I searched specifying the "/DataSource" context, would I get four property instances back? Two jndiName's and two maxConnectionPoolSize's? How would the jndiName and maxConnectionPoolSize for DataSource A get linked?

[ccrouch]

Until we drill into the ManagedObject to attachment metadata property/bean propertymapping I'm not sure the current view notion is adequate. The complexity of the ManagedObject as returned from an ear vs a data source is essentially unbounded.

Agreed. This mapping seems to be the biggest point for discussion currently. Lets see if we can determine how to move forward in the JBAS5 meeting tomorrow.

I want to try to stick to solving this problem for DataSources first and try to avoid getting swept out into the sea of complexity. To continue the water metaphor, I think we're just learning to paddle, so anywhere other than the shallow end (i.e. simple use cases) is not going to be helpful right now.

[starksm64]

Part of the property mapping definition should be a classification of the property from the perspective of an admin tool. In reality a property may be in multiple view/perspectives if we start talking about view likes "Server Ports", "Clustering", "Network Interfaces".

I'm not sure I fully understand this. Take for example two properties on a DataSource: the jndiName, and maxConnectionPoolSize. Would both of these properties get mapped to the /DataSource context?
Say I had two datasources deployed A and B, and I searched specifying the "/DataSource" context, would I get four property instances back? Two jndiName's and two maxConnectionPoolSize's? How would the jndiName and maxConnectionPoolSize for DataSource A get linked?

The querying of the view has not been defined. If it was a tree "DataSource/{Pool,Security}" and you asked for the DataSource tagged properties, you should get all. If you asked for the DataSource/Pool properties, you would only get the pool oriented properties.

If we want to query across deployments by view (and that certainly makes sense for many view, DataSources included), then yes, we should be returning 4 properties tied back to the 2 ManagedObjects for the 2 deployments.

[starksm64]

Agreed. This mapping seems to be the biggest point for discussion currently. Lets see if we can determine how to move forward in the JBAS5 meeting tomorrow.

I want to try to stick to solving this problem for DataSources first and try to avoid getting swept out into the sea of complexity. To continue the water metaphor, I think we're just learning to paddle, so anywhere other than the shallow end (i.e. simple use cases) is not going to be helpful right now.

Fundamentally the only diff between a DataSource and arbitrary ear should be the depth of the ManagedObject graphs, and the number of views that are available. What I would like to come up with in terms of the mapping is something simple, and yet sufficient to allow for the various extremes we are talking about. I have a view of what the mapping data might look like that I'm working to flesh out for discussion. I'll try to get this out tonight.