7 Replies Latest reply on Feb 25, 2009 8:55 AM by Emanuel Muckenhuber

    Bringing the trunk profile service changes to 5_x

    Scott Stark Master

      I took a look at merging the current trunk profile service changes into the Branch_5_x using just the 6.0.0.Alpha3 org.jboss.integration:jboss-profileservice-spi, but I see it has dependencies on updated deployer classes like org.jboss.deployers.client.plugins.deployment.AbstractDeployment. Are we going to be able to update the deployers and related jars?

      This is just the system subproject so far.

        • 1. Re: Bringing the trunk profile service changes to 5_x
          Emanuel Muckenhuber Master

           

          "scott.stark@jboss.org" wrote:
          I took a look at merging the current trunk profile service changes into the Branch_5_x using just the 6.0.0.Alpha3 org.jboss.integration:jboss-profileservice-spi, but I see it has dependencies on updated deployer classes like org.jboss.deployers.client.plugins.deployment.AbstractDeployment. Are we going to be able to update the deployers and related jars?


          Hmm actually the idea was to make the spi independent of the deployers project.
          Therefore we might want to drop the AttachmentStore from the spi, because it's actually creating a real Deployment.

          Furthermore - what's actually DeploymentTemplate.updateTemplate supposed to do?
          It's not implemented and i'm wondering why you should not call ManagementView.updateComponent ?
          Which is then the last thing referencing a VFSDeployment.

          The implementation uses the AbstractDeployment only because there is no DeploymentFactory.getInstance(),
          but shouldn't the AbstractDeployment already be in 5_x?


          • 2. Re: Bringing the trunk profile service changes to 5_x
            Scott Stark Master

             

            "emuckenhuber" wrote:

            Furthermore - what's actually DeploymentTemplate.updateTemplate supposed to do?
            It's not implemented and i'm wondering why you should not call ManagementView.updateComponent ?
            Which is then the last thing referencing a VFSDeployment.

            The notion was that the template might need to create the attachments that define the deployment after it has a VFSDeployment because it may not have put out enough information in the VirtualFile returned by the first phase when applyTemplate was called. A template may not want to have a complete xml or file based view of the properties what it writes out.

            "emuckenhuber" wrote:

            The implementation uses the AbstractDeployment only because there is no DeploymentFactory.getInstance(),
            but shouldn't the AbstractDeployment already be in 5_x?

            Yes, I found it. I thought it was in jboss-deployers-client-spi.jar, but turns out its in
            jboss-deployers-client.jar so its just that the system subproject dependencies did not include this.


            • 3. Re: Bringing the trunk profile service changes to 5_x
              Brian Stansberry Master

              Just an FYI, using the profile-service-spi currently in trunk plus subclassing a couple classes in system, I'm able to pretty simply get the required services in place to do what I want for an AS 5.1 clustered deployment repository. See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150107.

              • 4. Re: Bringing the trunk profile service changes to 5_x
                Emanuel Muckenhuber Master

                 

                "bstansberry@jboss.com" wrote:
                Just an FYI, using the profile-service-spi currently in trunk plus subclassing a couple classes in system, I'm able to pretty simply get the required services in place to do what I want for an AS 5.1 clustered deployment repository.


                Okay good, the current plan is that i'll start to port the changes from trunk to the 5.1 branch by the end of this week or starting next week.
                So we can also take a look then if there is still something missing for you.

                • 5. Re: Bringing the trunk profile service changes to 5_x
                  Emanuel Muckenhuber Master

                   

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

                  Furthermore - what's actually DeploymentTemplate.updateTemplate supposed to do?
                  It's not implemented and i'm wondering why you should not call ManagementView.updateComponent ?
                  Which is then the last thing referencing a VFSDeployment.

                  The notion was that the template might need to create the attachments that define the deployment after it has a VFSDeployment because it may not have put out enough information in the VirtualFile returned by the first phase when applyTemplate was called. A template may not want to have a complete xml or file based view of the properties what it writes out.


                  Hmm looking at applyTemplate() in ManagementView again, i noticed that applyTemplate() is actually creating a real file in a profile and therefore bypassing the minimal synchronization we have for ModifiedDeployments.

                  I think it would make more sense to use the DeploymentManager for this.
                  So it could write the template into a temp file and then use deploymentManager to distribute and deploy it?


                  • 6. Re: Bringing the trunk profile service changes to 5_x
                    Scott Stark Master

                     

                    "emuckenhuber" wrote:

                    Hmm looking at applyTemplate() in ManagementView again, i noticed that applyTemplate() is actually creating a real file in a profile and therefore bypassing the minimal synchronization we have for ModifiedDeployments.

                    I think it would make more sense to use the DeploymentManager for this.
                    So it could write the template into a temp file and then use deploymentManager to distribute and deploy it?

                    Yes, makes sense. The templating was written before we created the DeploymentManager.

                    • 7. Re: Bringing the trunk profile service changes to 5_x
                      Emanuel Muckenhuber Master

                      Hmm we could do it somehow like this:

                      public interface DeploymentTemplate
                      {
                       // Get the deployment info
                       DeploymentTemplateInfo getInfo();
                      
                       // Get the deployment name
                       String getDeploymentName(String baseName);
                      
                       // Apply template
                       VirtualFile applyTemplate(DeploymentTemplateInfo info);
                      }
                      


                      Where managementView is more or less doing this:
                       // Create a temp deployment
                       VirtualFile vf = template.applyTemplate(deploymentInfo);
                       // Get the deployment name
                       String deploymentName = template.getDeploymentName(baseName);
                       // Distribute deployment
                       deploymentMgr.distribute(deploymentName, vf.toURL(), true);
                       // Start deployment
                       deploymentMgr.start(deploymentName);
                       // Delete temp deployment
                       vf.delete();
                      


                      Although now i really don't know where to put this updateTemplateDeployment(VFSDeployment ctx, DeploymentTemplateInfo values);
                      IMO a deployment template does not need to know where it gets copied to. Furthermore it won't have access to the DeploymentContext until it's deployed anyway.
                      Also adding something to the deployments attachment would not make much sense, as it will get lost during the next startup.
                      I think additional updates to this template should use updateComponent() and be stored as a attachment.

                      There is also this in the SPI:
                       * TODO: this needs to be fleshed out in terms of the various pieces, raw deployment
                       * files, ManagedObjects, etc.
                      


                      not sure what you mean by that - so is there still something missing?