6 Replies Latest reply on Jun 27, 2008 10:43 AM by starksm64

    Deploying content installed after server start

    brian.stansberry

      Been digging into why my old VFSDeploymentScanner-based approach to deploying deploy-hasingleton content doesn't work to see if a temporary workaround was feasible for CR1 (tnot feasible and too late anyway, but that's not the point of this post). The problem I'm seeing looks like it would be a general one for any addition to a profile that's made after ProfileServiceBootstrap.start() executes.

      Basic issue is the VFSDeploymentScanner-based approach responds to becoming the singleton master by scanning deploy-hasingleton and invoking Profile.addDeployment(VFSDeployment, DeploymentPhase) for each item found. That works fine.

      What breaks is the profile impl ends up storing the deployment in a Map<String,VFSDeployment>. The deployment then gets added to the runtime by an HDScanner, which looks for modified deployments. The relevant bit can be boiled down to this pseudo-code:

      Iterator<VFSDeployment> iter = apps.iterator();
      while( iter.hasNext() )
      {
       VFSDeployment ctx = iter.next();
       VirtualFile root = ctx.getRoot();
       if ( root.hasBeenModified() ) // PROBLEM!!!
       {
       ... add to a list of things to deploy
       }
      }
      
      // Assume applicationDir points to deploy-hasingleton
      VirtualFile deployDir = VFS.getRoot(applicationDir.toURI());
      List<VirtualFile> children = deployDir.getChildren();
      for(VirtualFile vf : children)
      {
       String key = vf.toURI().toString();
       if( applicationCtxs.containsKey(key) == false ) // PROBLEM!!!
       {
       ... add to a list of things to deploy
       }
      }
      


      Problem is the 2 areas commented "PROBLEM!!!". In the first one, the newly added deployment doesn't get included in the modification list because the VirtualFile hasn't been modified. In the second case the newly added deployment doesn't get included in the modification list because the call to Profile.addDeployment() resulted in it getting added to the applicationCtxs map.

      So, the new content doesn't ever get deployed. I would expect that with any code that calls Profile.addDeployment(), the result would be the same -- the new deployment doesn't get installed into the runtime.

      For sure I see this with the basic ProfileService impl. Looking at the code I expect the same behavior with the repository-based impl, although I haven't confirmed that yet.

      I'll look around some more; also see if there are unit tests that cover this.

        • 1. Re: Deploying content installed after server start
          brian.stansberry

           

          I would expect that with any code that calls Profile.addDeployment(), the result would be the same -- the new deployment doesn't get installed into the runtime


          Searched around for usages of Profile.addDeployment(...). Besides the VFSScanner, the one I'm seeing is in ManagementViewImpl.applyTemplate(...). And there it seems to be calling the MainDeployer directly to get the new content installed:

          VFSDeployment ctx = deploymentFactory.createVFSDeployment(vf);
          activeProfile.addDeployment(ctx, phase);
          mainDeployer.addDeployment(ctx);
          


          Is that the recommended approach to this sort of thing? Makes sense in a way; adding content and then waiting for an arbitrarily timed scanner to pick it up seems wrong.

          • 2. Re: Deploying content installed after server start
            starksm64

            Yes, making the deployments in a profile available to the runtime is a separate step. Just updating a profile does not imply that the current server view is going to change.

            I understand what your saying about the getModifiedDeployments not behaving correctly for deployments added to the profile. Its the second PROBLEM you point out that needs to be addressed as the hasBeenModified call is just a VFS api.

            Can you create a bug report for that for CR2.

            • 3. Re: Deploying content installed after server start
              brian.stansberry
              • 4. Re: Deploying content installed after server start
                brian.stansberry

                 

                Yes, making the deployments in a profile available to the runtime is a separate step. Just updating a profile does not imply that the current server view is going to change.


                Makes sense. Adding calls to MainDeployer after I add/remove a deployment from the profile, and then doing a MainDeployer.process() at the end of the scan gets deploy-hasingleton deployment working. At least with the basic profile service. I'll see what happens with the repository based version.

                • 5. Re: Deploying content installed after server start
                  brian.stansberry

                  Just a follow up on this for the record. I got HASingletonDeploymentScanner to work with the repository based profile service as well, well enough at least for AS 5 CR1.

                  Basically, the HASingletonDeploymentScanner has the ProfileService and the MainDeployer injected. When the ProfileService is injected, it checks if it exposes a DeploymentManager. If yes, when it becomes master or stops being master it deploys/undeploys content via the DeploymentManager API (distibute, getRepositoryNames, start, stop, undeploy). The getRepositoryNames() method Scott added yesterday was most helpful. :)

                  If no DeploymentManager (i.e. the basic profile service) it deploys/undeploys by calling add/removeDeployment on the ProfileService and the MainDeployer and then tells the MainDeployer to process().

                  That's a temporary solution, but restores the feature, has educated Brian, and means there's now at least a unit test of deploy-hasingleton; never was one before.

                  http://jira.jboss.com/jira/browse/JBAS-5686

                  • 6. Re: Deploying content installed after server start
                    starksm64

                    Ok, great.