10 Replies Latest reply on Dec 21, 2006 8:53 PM by Scott Stark

    ManagementView changes

    Charles Crouch Expert

      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

        • 1. Re: ManagementView changes
          Scott Stark Master

           

          "charles.crouch@jboss.com" wrote:
          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.


          • 2. Re: ManagementView changes
            Scott Stark Master

             

            "charles.crouch@jboss.com" wrote:

            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.


            • 3. Re: ManagementView changes
              Scott Stark Master

               

              "charles.crouch@jboss.com" wrote:


              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.


              • 4. Re: ManagementView changes
                Scott Stark Master

                 

                "charles.crouch@jboss.com" wrote:


                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".


                • 5. Re: ManagementView changes
                  Scott Stark Master

                   

                  "charles.crouch@jboss.com" wrote:


                  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.

                  • 6. Re: ManagementView changes
                    Charles Crouch Expert

                     

                    "scott.stark@jboss.org" wrote:
                    "charles.crouch@jboss.com" wrote:

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


                    Ok, understood.


                    • 7. Re: ManagementView changes
                      Charles Crouch Expert

                       

                      "scott.stark@jboss.org" wrote:
                      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?


                      • 8. Re: ManagementView changes
                        Charles Crouch Expert

                         

                        "scott.stark@jboss.org" wrote:

                        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.

                        • 9. Re: ManagementView changes
                          Scott Stark Master

                           

                          "charles.crouch@jboss.com" wrote:
                          "scott.stark@jboss.org" wrote:

                          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.


                          • 10. Re: ManagementView changes
                            Scott Stark Master

                             

                            "charles.crouch@jboss.com" wrote:

                            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.