1 2 Previous Next 23 Replies Latest reply on Dec 22, 2006 11:05 AM by Adrian Brock

    Moving forward with the profile service mgmt api

    Charles Crouch Expert

      In the JBAS5 call this morning Adrian and I discussed how best we could proceed with fleshing out/writing tests for the management aspects of the profile service in parallel with Adrian developing the new managed object api and implementation. The conclusion that we came to was that the interface to Adrian's new managed objects would look quite similar to the ManagedObject/PropertyInfo interfaces we currently have. Therefore it should be possible to push ahead and build out the api's the profile service needs using the existing interfaces, and then refactor them when Adrian has committed his revised version. It should also be feasible to do the same with testcases, i.e. we write tests now and try to mock up/stub out interfaces that we require to get the tests going then come back and refactor later.

      There is definitely going to be rework needed when Adrians stuff lands but at least this approach should enable forward progress to be made in related areas in the meantime. The plan is in the JBAS5 call next week for Adrian to provide an estimate on when the new managed object api and impl would be available.

      Scott, does this approach make sense too you? Is it something you can push ahead with?

      Thanks

        • 1. Re: Moving forward with the profile service mgmt api
          Scott Stark Master

          Yes, but I need to get the PS using a deployment repository that holds the modified deployment metadata to effectively test this. That is what I hope to get done this weekend.

          • 2. Re: Moving forward with the profile service mgmt api
            Scott Stark Master

            Still too many distractions to get this done this weekend. I have checked in the current state. The two things to complete are getting the attachments for the base deployments stored in the repository, and then obtaining the attachments for a ManagedObject update to store as overrides. The profile repository notion I'm working with is defined by this spi:

            package org.jboss.profileservice.spi;
            
            import java.io.IOException;
            import java.io.InputStream;
            import java.net.URI;
            import java.util.Collection;
            import java.util.zip.ZipInputStream;
            
            import org.jboss.deployers.spi.attachments.Attachments;
            import org.jboss.deployers.spi.structure.DeploymentContext;
            import org.jboss.virtual.VirtualFile;
            
            /**
             * An interface for managing the contents of a Profile.
             *
             * @author Scott.Stark@jboss.org
             * @version $Revision:$
             */
            public interface DeploymentRepository
            {
             public URI getBootstrapURI();
             public void setBootstrapURI(URI uri);
             public URI getDeployersURI();
             public void setDeployersURI(URI uri);
             public URI getDeploymentURI();
             public void setDeploymentURI(URI rootURI);
            
             // Upload a raw deployment
             public VirtualFile addDeploymentFile(String name, ZipInputStream contentIS)
             throws IOException;
             // Get the raw deployment
             public VirtualFile getDeploymentFile(String name);
            
             // Bootstrap
             public void addBootstrap(String vfsPath, DeploymentContext ctx)
             throws IOException;
             public DeploymentContext getBootstrap(String vfsPath);
             public Collection<DeploymentContext> getBootstraps();
             public void removeBootstrap(String vfsPath)
             throws IOException;
            
             // Deployers
             public void addDeployer(String vfsPath, DeploymentContext ctx)
             throws IOException;
             public DeploymentContext getDeployer(String vfsPath);
             public Collection<DeploymentContext> getDeployers();
             public void removeDeployer(String vfsPath)
             throws IOException;
            
             // Deployments
             public void addDeployment(String vfsPath, DeploymentContext ctx)
             throws IOException;
             public DeploymentContext getDeployment(String vfsPath);
             public void removeDeployment(String vfsPath)
             throws IOException;
             public Collection<DeploymentContext> getDeployments();
            
             // Managed object attachments for a deployment
             public void addManagedObject(String vfsPath, Attachments edits)
             throws IOException;
            }
            



            • 4. Re: Moving forward with the profile service mgmt api
              Charles Crouch Expert

              So we've got a new ManagedObject api from Adrian. The underlying implementation is still being worked on
              http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/managed/src/main/org/jboss/managed/api/

              Also I understand that the meta data repository notion continues to be fleshed out:
              From Scott: "The two things to complete are getting the attachments for the base deployments stored in the repository, and then obtaining the attachments for a ManagedObject update to store as overrides."

              Questions about next steps:

              1) Does the additional work on the repository outlined above prevent progress on writing tests for the use cases we're going to need wrt basic DataSource management? I presume that the work remaining would actually prevent the tests from passing, but thats the next step :-). I guess we could stub out aspects of the repository to get the test to pass, but at the moment I'm more interested in the tests being written than having them pass.

              2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?

              3) The tests for the DataSource use cases should go in here?
              http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/tests/org/jboss/test/profileservice/test/

              Presumably the idea is that we can create our own mock impls or use the one Adrian has provided:
              http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/managed/src/main/org/jboss/managed/mock/MockDataSourceManagedObject.java

              Cheers

              • 5. Re: Moving forward with the profile service mgmt api
                Scott Stark Master

                 

                "charles.crouch@jboss.com" wrote:

                Questions about next steps:

                1) Does the additional work on the repository outlined above prevent progress on writing tests for the use cases we're going to need wrt basic DataSource management? I presume that the work remaining would actually prevent the tests from passing, but thats the next step :-). I guess we could stub out aspects of the repository to get the test to pass, but at the moment I'm more interested in the tests being written than having them pass.

                2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?

                It can be. The piece that is missing is how does the profile service take a ManagedObject populated with a set of changes, and then merge that into the base DeploymentContext metadata attachments to create the predetermined attachments that override the raw deployment values. The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties.

                The ManagementView also needs to be updated to support applying a ManagedObject change. I don't see that the ManagedObject returned from the ManagementView is hooked up to the attachments it overrides, therefore, this needs to be a write step.


                "charles.crouch@jboss.com" wrote:

                3) The tests for the DataSource use cases should go in here?
                http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/tests/org/jboss/test/profileservice/test/

                Presumably the idea is that we can create our own mock impls or use the one Adrian has provided:
                http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/managed/src/main/org/jboss/managed/mock/MockDataSourceManagedObject.java


                • 6. Re: Moving forward with the profile service mgmt api
                  Charles Crouch Expert

                   

                  "scott.stark@jboss.org" wrote:

                  It can be. The piece that is missing is how does the profile service take a ManagedObject populated with a set of changes, and then merge that into the base DeploymentContext metadata attachments to create the predetermined attachments that override the raw deployment values. The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties.

                  The ManagementView also needs to be updated to support applying a ManagedObject change. I don't see that the ManagedObject returned from the ManagementView is hooked up to the attachments it overrides, therefore, this needs to be a write step.


                  Ok, is this something you are going to looking at, or Adrian?

                  • 7. Re: Moving forward with the profile service mgmt api
                    Scott Stark Master

                    Its something I'm looking at.

                    • 8. Re: Moving forward with the profile service mgmt api
                      Adrian Brock Master

                       

                      "charles.crouch@jboss.com" wrote:

                      2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?


                      The ManagementView looks more like a profile service api than a deployers
                      or a managed object api?

                      • 9. Re: Moving forward with the profile service mgmt api
                        Adrian Brock Master

                         

                        "scott.stark@jboss.org" wrote:

                        The piece that is missing is how does the profile service take a ManagedObject populated with a set of changes, and then merge that into the base DeploymentContext metadata attachments to create the predetermined attachments that override the raw deployment values.


                        The initial construction of DeploymentContexts from the profile
                        is a problem for the profile service (with or without predetermined attachments).

                        Of course the managed object will provide a method to
                        turn a managed object into its wrapped attachment (metadata object)
                        for serialization by the profile service.

                        The piece that is missing outside the profile service
                        will be an extension to the deployers api where there will be two links:

                        1) You are a "parsing deployer", tell me what your managed object looks like.
                        i.e. construct a managed object for this attachment you created.

                        2) You want to support runtime updates (not just redeployment),
                        then the server side support of the managed object needs a link to the
                        "real deployer' for the attachment.


                        The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties.


                        Correct, in fact I'll talk about this in a seperate thread, because this is
                        my major stumbing block. Most of the other stuff I know how to do
                        and it is just a case of doing it, but this requires some extra thought.


                        The ManagementView also needs to be updated to support applying a ManagedObject change. I don't see that the ManagedObject returned from the ManagementView is hooked up to the attachments it overrides, therefore, this needs to be a write step.


                        To repeat what I said above (in pseudo code):
                        ManagedObject mo = parsingDeployer.getManagedObject(Attachment);
                        


                        Only each deployer/subsystem really knows how it wants to be managed.

                        With the usual caveats of providing implements/helpers for the deployer to choose
                        from and allowing overrides to fix up what the programmer of the deployer did (or did not) do. :-)

                        • 10. Re: Moving forward with the profile service mgmt api
                          Adrian Brock Master

                          Further to the FYI, I've updated the ManagedObject api to implement the AOP skeleton.

                          So it should be possible for Scott to intercept changes to the ManagedObject
                          and persist them according to whatever required. e.g.

                          * Persist on every change (simple)
                          * Persist when the user clicks "apply" (implemented a bit like transactions in JavaEE)
                          * Versioning (create a new version on every change or more lazily, e.g. only when
                          the user chooses to save the changes)
                          * etc.

                          In fact, I have a feeling that some of the simpler processing has a lot in
                          common with what POJO Cache does in terms of intercepting changes
                          and allowing atomic updates/rollbacks?

                          • 11. Re: Moving forward with the profile service mgmt api
                            Charles Crouch Expert

                             

                            "adrian@jboss.org" wrote:
                            "charles.crouch@jboss.com" wrote:

                            2) Should the org.jboss.deployers.spi.management.ManagementView be updated to use the new ManagedObject api?


                            The ManagementView looks more like a profile service api than a deployers
                            or a managed object api?


                            So are you advocating moving it or changing it?

                            • 12. Re: Moving forward with the profile service mgmt api
                              Charles Crouch Expert

                               

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

                              The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties.


                              Correct, in fact I'll talk about this in a seperate thread, because this is my major stumbing block. Most of the other stuff I know how to do and it is just a case of doing it, but this requires some extra thought.


                              Adrian,
                              The new thread you started:
                              http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97767
                              seems aimed at the more complicated use cases for this mapping. For Beta2 I would prefer us to concentrate on implementing and testing the simpler mapping cases first and then come back and revisit this in light of the more complicated ones. I think having a working implementation out there, even for just the simple case, will help us and others to think about this problem more concretely. If that means interfaces/impls need to change between Beta2 and the next release then so be it.

                              Does the ManagedObject to metadata object/properties mapping for DataSources fall into the "trivial" category?


                              • 13. Re: Moving forward with the profile service mgmt api
                                Adrian Brock Master

                                If I understand what it does from the javadoc then yes, I'd say
                                it should be moved to the profile service api?

                                The actual implementation would probably delegate most of the work
                                to the deployer(s), but the deployers or managed object api don't know
                                what a profile or version is.

                                The deployers and managed objects api are primitives used by the profile service.

                                It does bring up one "todo" which is to flesh out the
                                deployment/managed object/attachment identity notions.
                                I haven't come across anything that uses this yet, but I imagine Scott might
                                have to deal with the issue in what he is working on?

                                • 14. Re: Moving forward with the profile service mgmt api
                                  Adrian Brock Master

                                   

                                  "charles.crouch@jboss.com" wrote:
                                  For Beta2 I would prefer us to concentrate on implementing and testing the simpler mapping cases first and then come back and revisit this in light of the more complicated ones.


                                  That was my conclusion as well, if you read the last paragraph.

                                  It was Scott that brought up the issue of more complicated structures.
                                  The DataSource isn't that complicated (at least at the front end management level :-)

                                  1 2 Previous Next