1 2 3 Previous Next 36 Replies Latest reply: Feb 11, 2010 3:13 PM by Brian Stansberry Go to original post RSS
      • 30. Re: Deployment of on-demand web applications
        Brian Stansberry Master

        The full stack trace shows this is actually a later scan by the HDScanner that is failing:

         

        2:24:56,739 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to PreReal: name=vfsfile:/home/bes/dev/jboss/clean/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/deploy/jmx-console.war/WEB-INF/web.xml state=PostClassLoader mode=Manual requiredState=PreReal: org.jboss.deployers.spi.DeploymentException: java.lang.ClassNotFoundException: org.jboss.jmx.adaptor.html.HtmlAdaptorServlet from BaseClassLoader@1dc5e181{vfsfile:/home/bes/dev/jboss/clean/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/deploy/jmx-console.war/WEB-INF/web.xml}
            at org.jboss.resteasy.integration.deployers.ResteasyScannerDeployer.deployApplicationClass(ResteasyScannerDeployer.java:112)
            at org.jboss.resteasy.integration.deployers.ResteasyScannerDeployer.internalDeploy(ResteasyScannerDeployer.java:57)
            at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55)
            at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
            at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1660)
            at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1378)
            at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1319)
            at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:378)
            at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1956)
            at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1019)
            at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1251)
            at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1175)
            at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1073)
            at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:887)
            at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602)
            at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:898)
            at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:677)
            at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
            at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:409)
            at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:294)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
            at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
            at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
            at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
            at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
            at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
            at java.lang.Thread.run(Thread.java:619)
        Caused by: java.lang.ClassNotFoundException: org.jboss.jmx.adaptor.html.HtmlAdaptorServlet from BaseClassLoader@1dc5e181{vfsfile:/home/bes/dev/jboss/clean/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/deploy/jmx-console.war/WEB-INF/web.xml}
            at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:498)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
            at org.jboss.resteasy.integration.deployers.ResteasyScannerDeployer.deployApplicationClass(ResteasyScannerDeployer.java:108)
            ... 28 more

         

        I suspect I'm not setting up the profile correctly for hot deployment; i.e. the base URL that's scanned is the root of the war, rather than some parent like /deploy/. I'll check; I bet this happens with -Djboss.as.deployment.ondemand=true as well; it's just deferred until after you trigger the deployment.

        • 31. Re: Deployment of on-demand web applications
          Brian Stansberry Master

          Running in a debugger confirms that the HDScanner is treating each file inside the war as a new deployment. This doesn't happen with -Djboss.as.deployment.ondemand=true because there's a bug in the way profiles are configured for HD scanning. It only gets turned on via this bit in ProfileServiceBootstrap.start(...)

           

                // Enable modification checks on all mutable profiles 
                for(ProfileKey key : profileService.getActiveProfileKeys())
                {
                   try
                   {
                      Profile profile = profileService.getActiveProfile(key);
                      if(profile.isMutable() && profile instanceof MutableProfile)
                      {
                         ((MutableProfile) profile).enableModifiedDeploymentChecks(true);
                      }
                   }
                   catch(NoSuchProfileException ignore) { }
          

           

          With -Djboss.as.deployment.ondemand=true when that code executes, the profiles for the on-demand wars are not yet "active" so the enableModifiedDeploymentChecks(true) call is never made.  With -Djboss.as.deployment.ondemand=false the profile is active and the profile is exposed to the HDScanner.

          • 32. Re: Deployment of on-demand web applications
            Brian Stansberry Master
            https://jira.jboss.org/jira/browse/JBAS-7721 to fix ProfileService problem; https://jira.jboss.org/jira/browse/JBAS-7720 to then figure out how to set up the profile such that the HD scan understands that it's not supposed to look at each file in the war as a deployment.
            • 33. Re: Deployment of on-demand web applications
              Emanuel Muckenhuber Master

              IMHO no deployment outside of "hot-deployment profile" should be checked for modifications. In future (once i integrated the new profileservice stuff) hot-deployment won't be available for any jboss deployments anymore. Redeployment will only happen as part of a ManagementAction - where we know if we have to restart the whole server to apply changes or can just redeploy the deployment.

               

              So i would rather prefer to just disbale hot-deployment checking for those deployments in general - what do you think?

              • 34. Re: Deployment of on-demand web applications
                Brian Stansberry Master

                Fair enough. The above JIRAs are mostly to document this for later consideration so I could move on to other stuff today.

                 

                I don't see much use case for hot deploying these apps. If someone really wanted to they could just move them to the hot deploy profile.

                 

                Hmm, but deploy-hasingleton is a bit of a different story. That's a profile that gets activated after startup but is a legit hot deploy profile. For that we'd need to make sure the JBAS-7721 problem is fixed.

                • 35. Re: Deployment of on-demand web applications
                  Emanuel Muckenhuber Master

                  bstansberry@jboss.com wrote:

                   

                  Fair enough. The above JIRAs are mostly to document this for later consideration so I could move on to other stuff today.

                   

                  Well i mean there is obviously something broken, i don't want to argue about that. That HDScanner is picking up the contents of the .war is because i added some workaround to integrate service-bindingmanager. I never thought this should be hot-deployable, so i was wrong. However i need to validate if this is still true for some new profiles i'm going to add - so might just remove this workaround and you would need to use a different metadata to create this kind of profiles.

                   

                  bstansberry@jboss.com wrote:

                   

                  Hmm, but deploy-hasingleton is a bit of a different story. That's a profile that gets activated after startup but is a legit hot deploy profile. For that we'd need to make sure the JBAS-7721 problem is fixed.

                   

                  Currently the activator has to take care of that e.g. profileService.getActiveProfile(key).isMutable().enableModificationChecks(...);

                   

                  HDScanning will change a bit in future. So basically i want to have a HDScanner per "hot-deployment profile", so that they can have a separate scan-period and the scanner can be started/stopped independently. I haven't finished the implementation yet, so i cannot really say how this will exactly look like. I guess i can add a "startAutomatically" flag to the scanner configuration, so that an activator does not need to take care of that in future?

                  • 36. Re: Deployment of on-demand web applications
                    Brian Stansberry Master

                    Yeah, I think something that activates a hot-deployment profile shouldn't have to worry about triggering the scanning; that should be internal to the hot-deployment profile.

                    1 2 3 Previous Next