6 Replies Latest reply on Nov 5, 2007 8:49 AM by Adrian Brock

    Generalizing supply/demand

    Scott Stark Master

      The current problem with using the ejb3 client deployer as a general client deployer is that its container bean is looking for suppliers of things like a jndi name binding. The problem is that supply/demand is a kernel bean specific notion. It does not show up in the Controller api. It shows up in the KernelController. The problem with this is that the jmx mbean service controller cannot express that its contexts supply the demands of an MC bean context. So when you have a legacy client application deployment that does not involve ejb3 components, there ends up being nothing to supply the demands of the client container bean.

      Either supply/demand should just be a type of dependency where a demand maps onto a DependencyItem and supply maps to an alias, or we need the supply/demand notion to show up at the more general ControllerContext/Controller level to allow supply/demand to span different context implementations.

        • 1. Re: Generalizing supply/demand
          Ales Justin Master

          Can't we/they simply re-write those mbean to MC beans?
          I'm in favor of encouraging people to use MC beans where ever possible, even if that means rewriting some code.

          Demand already is a simple DependencyItem.
          And I just extended it with some 'matching' notion.

          • 2. Re: Generalizing supply/demand
            Scott Stark Master

             

            "alesj" wrote:
            Can't we/they simply re-write those mbean to MC beans?

            No.

            'ales' wrote:

            Demand already is a simple DependencyItem.
            And I just extended it with some 'matching' notion.

            I don't see how an mbean can satisfy the demand of an mc bean with the current spi because the matching of demand to supply does not use the mc bean independent apis.


            • 3. Re: Generalizing supply/demand
              Ales Justin Master

               

              "scott.stark@jboss.org" wrote:
              "alesj" wrote:
              Can't we/they simply re-write those mbean to MC beans?

              No.

              Uf. :-)
              btw: why not?

              "scott.stark@jboss.org" wrote:

              'ales' wrote:

              Demand already is a simple DependencyItem.
              And I just extended it with some 'matching' notion.

              I don't see how an mbean can satisfy the demand of an mc bean with the current spi because the matching of demand to supply does not use the mc bean independent apis.

              It can't. :-)
              It can only demand whatever with legacy 'demand' element.
              I have no objections with moving demand/supply notion to our dependency module. Although this bloats simple 'state machine' impl in dependency.

              • 4. Re: Generalizing supply/demand
                Scott Stark Master

                 

                "alesj" wrote:

                Uf. :-)
                btw: why not?

                Because its unnecessary busy work. What's the point of a multi-container kernel if you don't use multiple container types?


                'ales' wrote:

                It can't. :-)
                It can only demand whatever with legacy 'demand' element.
                I have no objections with moving demand/supply notion to our dependency module. Although this bloats simple 'state machine' impl in dependency.

                If supply/demand are to be mc bean specific it simply cannot be used as a cross-container mechanism. It seems like this can be replaced with a dependency on an alias, in which case, that is how the mc supply/demand should be implemented.


                • 5. Re: Generalizing supply/demand
                  Ales Justin Master

                   

                  "scott.stark@jboss.org" wrote:

                  Because its unnecessary busy work. What's the point of a multi-container kernel if you don't use multiple container types?

                  That's why I was asking if there is a tool to do this for you. :-)
                  Not all container shoes fit all container feet. ;-)
                  You don't want to push all features to all impls/legacy.

                  "scott.stark@jboss.org" wrote:

                  If supply/demand are to be mc bean specific it simply cannot be used as a cross-container mechanism. It seems like this can be replaced with a dependency on an alias, in which case, that is how the mc supply/demand should be implemented.

                  Yes, this is a legit/current workaround.
                  You can add an alias to mbean, which will work as a supply for any MC bean.

                  • 6. Re: Generalizing supply/demand
                    Adrian Brock Master

                     

                    "scott.stark@jboss.org" wrote:

                    It can only demand whatever with legacy 'demand' element.
                    I have no objections with moving demand/supply notion to our dependency module. Although this bloats simple 'state machine' impl in dependency.
                    If supply/demand are to be mc bean specific it simply cannot be used as a cross-container mechanism. It seems like this can be replaced with a dependency on an alias, in which case, that is how the mc supply/demand should be implemented.


                    There already is an abitrary alias mechanism in the ControllerContext.

                    The Demand/Supply mechanism predates this and is probably obsolete
                    now with the full alias dependency mechanism that Ales did a couple of months ago.

                    i.e. you can change supply -> alias and demand -> depends

                    On the cross controller issue, that's just an implementation detail.

                    It's only implemented in the KernelController because I'm lazy
                    I didn't want to create another object in the kernel bootstrap e.g. SupplyRegistry
                    to hold the registrations.

                    It has nothing to do with the controller, it is just a registry that is integrated
                    into the dependency mechanism by being a KernelRegistryPlugin.
                    i.e. The KernelController just happens to implement KernelRegistryPlugin
                    so it can say when Supplies are there.