6 Replies Latest reply on Feb 1, 2007 1:32 PM by Scott Stark

    Precedence level

    Bill Burke Master

      I'm looking at the Seam component model to see how it could be merged with MC. Here's an interesting feature they got.

      When you deploy a component, it can have both dependencies as well as a precedence level. Basically the precedence level is a numerical value of where in the chain the component should be deployed. Gavin uses this so that somebody could say: "I want this component deployed after all Seam BUILT IN components".

      Maybe we could translate this into logical groupings of beans:

      <bean name="Foo" group="BUILT IN" .../>
      <bean name="Bar" group="BUILT IN" .../>
      
      
      <bean name="MyStuff">
       <depends-group>BUILT IN</depends-group>
      </bean>
      


      "MyStuff" would have a logical dependency to Foo and Bar through the "BUILT IN" tag.



        • 1. Re: Precedence level
          Adrian Brock Master

          The problem with this is that it works fine for Seam or Spring where you
          are only dealing with a single application with a fixed set of deployments.

          The MC has to deal with hotdeployment where beans can be added at anytime.

          e.g. suppose we define a jboss-jca group so you can depend upon
          all of jca being deployed, but then you add a new rar to the jboss-jca group?

          • 2. Re: Precedence level
            Scott Stark Master

            A dependency + an order is just introduces an implicit dependency on the components in the dependency tree with a lower order. The problem is defining the dependency tree as Adrian points out. We would need some alternate dependency scope notion that could be restricted to the current top-level deployment, as an example.

            • 3. Re: Precedence level
              Bill Burke Master

               


              e.g. suppose we define a jboss-jca group so you can depend upon
              all of jca being deployed, but then you add a new rar to the jboss-jca group?


              I see your point. The aliased dependent components would not be allowed to start until a complete scan was complete. So, you couldn't resolve dependencies until every single deployment in the system had been at least described.

              • 4. Re: Precedence level
                Adrian Brock Master

                 

                "bill.burke@jboss.com" wrote:
                So, you couldn't resolve dependencies until every single deployment in the system had been at least described.


                Which is something that could only be defined with reference to something
                like the profile service.

                • 5. Re: Precedence level
                  Pete Muir Master

                   

                  "bill.burke@jboss.com" wrote:
                  When you deploy a component, it can have both dependencies as well as a precedence level. Basically the precedence level is a numerical value of where in the chain the component should be deployed. Gavin uses this so that somebody could say: "I want this component deployed after all Seam BUILT IN components".


                  Just to clarify, precedence is actually used to say "I want this component used INSTEAD OF this other component (with the same name)". So if I had a built-in-to-seam component foo (precedence 0) and a component I had developed also called foo, but with precedence 40, my component would get used instead of the built in one (both by Seam and by my app).

                  • 6. Re: Precedence level
                    Scott Stark Master

                    That is an mc supplies notion with duplicate resolution based on the precedence number. It still leaves the problem of knowing what the universe of suppliers is. I suppose if seam components are deployed at the application phase in terms of the profile service notions of bootstrap, deployers, application phases, the phase deployer processing defines the supplier universe.