9 Replies Latest reply on Dec 19, 2001 11:35 AM by Adrian Brock

    DeployerMBeanSupport to restrictive

    David Maddison Newbie

      In DeployerMBeanSupport::deploy(String url) it checks to see if the URL has been deployed, if it has, it stops the re-deployment, stating it's already deployed.

      When creating a new deployer based on DeployerMBeanSupport, I find this to restrictive. It would be cool, and less work for me, if it could automatically call undeploy(url, info), rather than stop the deployment. After all, it must be a re-deployment for some reason, because otherwise the autodeployer wouldn't have called it!

        • 1. Re: DeployerMBeanSupport to restrictive
          Adrian Brock Master

          Hi,

          I've been looking at adding a method
          redeploy(URL) to DeployerMBeanSupport.

          The default implementation would be as now,
          but each deployer could change the behaviour.

          Potentially, the redeploy() could handshake the old
          deployment with the new one avoiding any loss of
          service.

          I haven't got very far with it. I couldn't work out
          where the responsibilties lie between the AutoDeployer and the Deployer, my implementation got confused with the different behaviour of J2eeDeployer and DeployerMBeanSupport.
          I don't think the required behaviour is defined.

          It would be nice to be able to fix the AutoDeployer, get the old AutoDeployer to deploy the new one and hand its url watches over.

          Of course there is a problem with the JMX registration, I haven't figured that one out yet!

          Regards,
          Adrian

          • 2. Re: DeployerMBeanSupport to restrictive
            Adrian Brock Master

            And of course,

            your deployer can just do

            void redeploy(URL u)
            {
            undeploy(u);
            deploy(u);
            }

            Regards,
            Adrian

            • 3. Re: DeployerMBeanSupport to restrictive
              David Maddison Newbie

              but DeployerMBeanSupport-Deploy(String) is called by the AutoDeployer, and as such you cann't get in before it. If a deployment is already registered and the AutoDeployer, calls deploy then the deployer should unregister the current deployment and do a re-deploy. I don't think there's a need for a redeploy method.

              It appears that DeployerMBeanSupport was built for the service deployer.

              • 4. Re: DeployerMBeanSupport to restrictive
                Adrian Brock Master

                Hi,

                I was thinking of making it more like JNDI and rebind.
                Just like JNDI you can't use bind when something is already bound to that name.

                If the AutoDeployer knows it is already deployed it can invoke redeploy to allow the deployer to optimize the redeployment.

                Alternatively, DeployerMBeanSupport could redeploy by default.
                If the deployer doesn't like redeploy it can always raise an exception or warning.

                Regards,
                Adrian

                • 5. Re: DeployerMBeanSupport to restrictive
                  David Jencks Master

                  IM not very humble opinion autodeployer needs to undeploy and redeploy when it detects a timestamp change. Putting the responsibility elsewhere would be a large error IMO. I've been planning this change for a couple of months but keep getting sidetracked. If anyone else wants to take a look be my guest.

                  • 6. Re: DeployerMBeanSupport to restrictive
                    Adrian Brock Master

                    Hi,

                    undeploy();
                    deploy();

                    seems to work for both the ServiceDeployer and the RARDeployer,
                    both derived from DeployerMBeanSupport

                    at least from my testing

                    seems => I haven't run the testsuite over it,
                    but then I never managed to get the testuite to not hang(deadlock??) the few times I've tried to run it :-(

                    I'll post it to the dev-list see, if anybody has a good reason for this not being the behaviour.

                    Regards,
                    Adrian

                    • 7. Re: DeployerMBeanSupport to restrictive
                      Adrian Brock Master

                      Not much response from the dev-list,
                      but then it is a Sunday. In fact only David.

                      So its 3 votes to nil for doing
                      undeploy()
                      deploy()
                      in the AutoDeployer

                      I'm still a bit concerned about Auto-redeploying
                      services and getting suspensions.
                      But maybe that's just something that Sys-admins should
                      be aware of.

                      Regards,
                      Adrian

                      • 8. Re: DeployerMBeanSupport to restrictive
                        David Jencks Master


                        > I'm still a bit concerned about Auto-redeploying
                        > services and getting suspensions.

                        What specifically are your concerns? Everything that stopped as a consequence of an undeploy should start again as a consequence of the [re]deploy. Marc may be removing the dependency management based on the service.xml classpath element, but mbean-ref dependencies I think (and hope) he is keeping. I figured that if you changed a file, you meant it, and all the dependencies should be taken care of, so for instance if you changed an mbean class and redeployed the jar containing it all the mbeans of that class should be undeployed and redeployed automatically when the new class becomes available. It's not quite this nice at the moment with classes, there's just classpath declarations of dependencies, but undeploy and auto-redeploy seem to work ok. (Marc has been working on this code, and I don't know what his plans are. This is how it works in cvs today.)

                        • 9. Re: DeployerMBeanSupport to restrictive
                          Adrian Brock Master

                          Hi,

                          My only concern was accidentially changing a service.
                          It's probably best if we don't try to cater for
                          accidents :-)

                          Regards,
                          Adrian