14 Replies Latest reply on Oct 13, 2006 1:27 PM by starksm64

    Ordering of nested deployments

    kabirkhan

      Is the idea that inner deployments will be deployed before outer deployments eventually? This does not look like it is the case at the moment.

      2006-10-09 19:10:37,765 DEBUG [org.jboss.deployers.plugins.deployment.MainDeployerImpl] Scheduling deployment: jar:file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-extendertest.sar!/
      2006-10-09 19:10:37,765 DEBUG [org.jboss.deployers.plugins.deployment.MainDeployerImpl] Scheduling deployment: jar:file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-extendertest.sar!/aop-extendertest.aop
      2006-10-09 19:10:37,765 TRACE [org.jboss.deployers.plugins.deployers.kernel.BeanDeployer] Deploying: jar:file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-extendertest.sar!/
      2006-10-09 19:10:37,765 TRACE [org.jboss.deployers.plugins.deployers.kernel.BeanDeployer] Deployed: jar:file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-extendertest.sar!/
      2006-10-09 19:10:37,765 TRACE [org.jboss.deployers.plugins.deployers.kernel.BeanDeployer] Deploying: jar:file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-extendertest.sar!/aop-extendertest.aop
      2006-10-09 19:10:37,765 TRACE [org.jboss.deployers.plugins.deployers.kernel.BeanDeployer] Deployed: jar:file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/testsuite/output/lib/aop-extendertest.sar!/aop-extendertest.aop
      
      


        • 1. Re: Ordering of nested deployments
          starksm64

          Currently all deployments are added to a list in breadth first order. Previously I had a plugin that would return a directed graph of the contexts in a given top level deployment which allowed this to be configurable. This or some other metadata to control this for backward compatibility seems needed.

          • 2. Re: Ordering of nested deployments

            Why?

            This is just scheduling of deployments. It says, I'm going to deploy
            these components.

            The real deployment is done width first in a staged manner.

            So it should be case that for example in aop, it does:
            Stage 1) Parse *all* aop configurations into aop metadata
            Stage 2) Add *all* aop metadata (including those passed in the predetermined objects rather than parsed from xml) to the aspect manager
            Stage 3) Create *all* classloaders
            Stage 4) Use the aop enhanced classes in other deployers/runtime

            I don't see the need to differentiate inner from outer deployments?

            Is there a case where stage N of an outer deployment depends
            upon stage N of an inner deployment?
            Why?

            • 3. Re: Ordering of nested deployments
              bill.burke

              Kabir,

              Conceptually, I had a lot of the same questions and issues that you are raising until I got used to the idea of breaking up a single deployer into multiple deployers that handle their specific narrowed task. It actually turns out to be much much cleaner.

              Bill

              • 4. Re: Ordering of nested deployments
                kabirkhan

                Aaaah, that actually makes a lot of sense now - thanks guys :-)

                If I have understood correctly the ordering of the aspect deployers is what is important. I need to make the AOP deployer be one of the first aspect deployers in the chain. Is there a way to configure the order of the aspect deployers in the MainDeployer? I need the AOP metadata to be deployed before it attempts to load any of the classes, but it should happen after any classloaders have been created since that information is used for AOP scoped by classloader.

                The easiest way to achieve this would be to hardocde the aspect stuff into the conf/deployer-beans.xml, but I am not sure if this is the way to go?

                I've commited a first packaging of the AOP deployer (without annotation support). For now I have put the AOP jars in the lib/ directory, the aspect-deployer-beans.xml in the deployers/ directory and the base-aop.xml in the conf/ directory. I was going to keep the jboss-aop-jdk50.deployer, but doing it that way meant that the ejb3-interceptors-aop.xml file was not getting deployed since that got deployed before the AOP deployer itself (there is a TODO in MainDeployerImpl to process existing deployments)

                • 5. Re: Ordering of nested deployments

                  The ordering is determined by the getRelativeOrder()
                  defined on the Deployer interface.

                  If you extend the standard deployer, e.g. AbstractParsingDeployer
                  you get a default ordering based on the type
                  which are defined on the interface:

                  public interface Deployer
                  {
                   /** The parser order */
                   public static final int PARSER_DEPLOYER = 2000;
                  
                   /** The class loader order */
                   public static final int CLASSLOADER_DEPLOYER = 4000;
                  
                   /** The component order */
                   public static final int COMPONENT_DEPLOYER = 4000;
                  
                   /** The real order */
                   public static final int REAL_DEPLOYER = 10000;
                  


                  Feel free to add new ones, e.g. AspectManager population something like?

                   /** The preprocess classloader order */
                   public static final int PREPROCESS_CLASSLOADING_DEPLOYER = 3900;
                  


                  • 6. Re: Ordering of nested deployments
                    kabirkhan

                    Ok, thanks.

                    Why do CLASSLOADER_DEPLOYER and COMPONENT_DEPLOYER have the same value? I need something greater than 4000 since I need the classloader to have been created, but I am not sure what the component deployers do?

                    Should anything apart from the real deployers actually instantiate deployment classes?

                    • 7. Re: Ordering of nested deployments

                       

                      "kabir.khan@jboss.com" wrote:
                      Ok, thanks.

                      Why do CLASSLOADER_DEPLOYER and COMPONENT_DEPLOYER have the same value? I need something greater than 4000 since I need the classloader to have been created, but I am not sure what the component deployers do?


                      I didn't notice. It's obviously wrong and a cut and paster error. :-)

                      Should anything apart from the real deployers actually instantiate deployment classes?

                      • 8. Re: Ordering of nested deployments

                        The component deployers split up a deployment into components
                        so the real deployers are easier to write (they just deal with one component).

                        It should probably be around 7000

                        e.g.
                        -serivce.xml (ServiceDeploymentMetaData) is split into mbeans (ServiceMetaData)
                        -beans.xml (KernelDeployment) is split into pojos (BeanMetaData)
                        etc.

                        Also other deployers can target your real deployer at the atomic
                        level. e.g. the RARDeployer creates a ServiceMetaData (mbean for the rar)
                        without having to go through the full ServiceDeployment stuff.
                        I'd imagine you could do something similar with AOP if you
                        had a custom deployer that wanted to create a simple aspect
                        not the full -aop.xml

                        It makes it possible to write simple deployers that can do
                        things at the most atomic level with the metadata without having
                        to understand how to iterate.

                        Finally, it makes the real deployers less error prone since the
                        MainDeployer knows how to correctly unwind a failed deployment
                        if one of the components fails.

                        • 9. Re: Ordering of nested deployments
                          bill.burke

                           

                          "scott.stark@jboss.org" wrote:
                          Currently all deployments are added to a list in breadth first order. Previously I had a plugin that would return a directed graph of the contexts in a given top level deployment which allowed this to be configurable. This or some other metadata to control this for backward compatibility seems needed.


                          This ordering needs to be nailed down. Why? Please take a look at the server/ module under

                          org.jboss.deployment.JaccInitializationDeployer and JaccCommitDeployer.

                          Unless I am misunderstanding JACC, the parent PC cannot commit until all child PCs are linked. So, the implementation of these deployers is dependent on the ordering of deployment units. My implementation depends on Bredth-first, as initialisation creates and links the PC while commit just commits. I'll have to switch where the link happens based on whether it is depth/bredth.



                          • 10. Re: Ordering of nested deployments
                            starksm64

                            You understanding is correct. The problem as I see it is that this is really more of a component lifecycle issue rather than a deployer issue. In our old deployment framework deployment and component lifecycle were tightly coupled. Now the deployers are just translating metadata into kernel beans, and the kernel lifecycle/dependency should be triggering things like commiting the PCs before the deployment components are fully started. The associated java.security.Policy object also needs to be refreshed after this.

                            The best way would be to hook in a JaccSetup pojo would be a bean apon which the "container" beans dependend. Maybe this is best done via injection of the bean representing the security domain. I think its just going to take a fair amount of refactoring to properly leverage the mc where approriate.

                            • 11. Re: Ordering of nested deployments
                              starksm64

                               

                              "adrian@jboss.org" wrote:

                              This is just scheduling of deployments. It says, I'm going to deploy
                              these components.

                              The real deployment is done width first in a staged manner.

                              I don't see the need to differentiate inner from outer deployments?

                              Is there a case where stage N of an outer deployment depends
                              upon stage N of an inner deployment?
                              Why?


                              How do I control the order in which deployers that both rely on ServiceMetaData components to have these services started in the correct order? Its the old issue of lacking explicit service dependencies, having a coarse module based ordering mechanism. Currently the war deployer is a AbstractSimpleRealDeployer with the same relative order as the RARDeployer. A war with a nested rar has no guarentee of correct startup of the rar without an explicit dependency on its service. Maybe it will be irrelevant in the end as interaction with the rar services will be through injection and the required dependencies will show up, and this will be a non-issue.


                              • 12. Re: Ordering of nested deployments
                                starksm64

                                 

                                "adrian@jboss.org" wrote:
                                Why?
                                ...
                                Is there a case where stage N of an outer deployment depends
                                upon stage N of an inner deployment?

                                One circumstance where there is a conflict between the structural parse and deployment phase is when adding a deployer which contains deployments. The war deployers contained in a jbossweb-tomcat6.deployer package also contains a ROOT.war. The structural pase phase identifies the jbossweb-tomcat6.deployer and jbossweb-tomcat6.deployer/ROOT.war as deployment contexts, but the deployer list is fixed going into the deploy loop.

                                Other than getting into full hotdeployment of deployers, we would need a notion of retrying deployment contexts that had no deployer if a deployer was added during a deploy loop.


                                • 13. Re: Ordering of nested deployments

                                   

                                  "scott.stark@jboss.org" wrote:
                                  The war deployers contained in a jbossweb-tomcat6.deployer package also contains a ROOT.war. The structural pase phase identifies the jbossweb-tomcat6.deployer and jbossweb-tomcat6.deployer/ROOT.war as deployment contexts, but the deployer list is fixed going into the deploy loop.


                                  This is case where deployer and container are incorrectly mixed together.
                                  ROOT.war is a runtime component that shouldn't be part of the
                                  deployer deployment.

                                  • 14. Re: Ordering of nested deployments
                                    starksm64

                                     

                                    "adrian@jboss.org" wrote:

                                    This is case where deployer and container are incorrectly mixed together.
                                    ROOT.war is a runtime component that shouldn't be part of the
                                    deployer deployment.


                                    Not that I disagree, and have said we should pull the ROOT.war out of the tomcat sar in the past.