1 2 Previous Next 17 Replies Latest reply on Jul 27, 2007 11:06 AM by Scott Stark

    JBMICROCONT-181 & ManagedDeployments

    Scott Stark Master

      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.

        • 1. Re: JBMICROCONT-181 & ManagedDeployments
          Adrian Brock Master

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

          • 2. Re: JBMICROCONT-181 & ManagedDeployments
            Adrian Brock Master

            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.

            • 3. Re: JBMICROCONT-181 & ManagedDeployments
              Scott Stark Master

               

              "adrian@jboss.org" wrote:

              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.

              "adrian@jboss.org" wrote:

              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.

              "adrian@jboss.org" wrote:

              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.


              • 4. Re: JBMICROCONT-181 & ManagedDeployments
                Scott Stark Master

                 

                "adrian@jboss.org" wrote:

                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.

                "adrian@jboss.org" wrote:

                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.

                • 5. Re: JBMICROCONT-181 & ManagedDeployments
                  Adrian Brock Master

                   

                  "scott.stark@jboss.org" wrote:

                  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.

                  • 6. Re: JBMICROCONT-181 & ManagedDeployments
                    Scott Stark Master

                     

                    "adrian@jboss.org" wrote:
                    "scott.stark@jboss.org" wrote:

                    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.

                    • 7. Re: JBMICROCONT-181 & ManagedDeployments
                      Adrian Brock Master

                      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.

                      • 8. Re: JBMICROCONT-181 & ManagedDeployments
                        Charles Crouch Expert

                         

                        "scott.stark@jboss.org" wrote:

                        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.

                        "adrian@jboss.org" wrote:

                        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

                        • 9. Re: JBMICROCONT-181 & ManagedDeployments
                          Adrian Brock Master

                           

                          "charles.crouch@jboss.com" wrote:

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

                          • 10. Re: JBMICROCONT-181 & ManagedDeployments
                            Adrian Brock Master

                             

                            "adrian@jboss.org" wrote:

                            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.


                            • 11. Re: JBMICROCONT-181 & ManagedDeployments
                              Adrian Brock Master

                               

                              "adrian@jboss.org" wrote:

                              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!

                              • 12. Re: JBMICROCONT-181 & ManagedDeployments
                                Scott Stark Master

                                 

                                "adrian@jboss.org" wrote:
                                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.


                                • 13. Re: JBMICROCONT-181 & ManagedDeployments
                                  Scott Stark Master

                                  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.



                                  • 14. Re: JBMICROCONT-181 & ManagedDeployments
                                    Adrian Brock Master

                                     

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

                                    1 2 Previous Next