4 Replies Latest reply on Feb 28, 2007 10:52 AM by Adrian Brock

    Automatic Scoped Kernels - A good idea

    Adrian Brock Master

      Given Ales's latest issue/hack,

      I'm beginning to wonder whether the automatic construction of scoped
      kernels is really such a good idea.

      For ease of use it probably is, but making it work is requiring too many hacks
      and I have a feeling that Ales is doing it wrong anyway or has at least
      misunderstood part of it (Given some of the problems he is reporting).

      The alternate approach would be to move the scoping of kernels to the deployers.
      i.e. The MC can support scoped kernels but you have to use an api
      to configure them.

      The deployment chain would then look something like:
      1) Parsing as now (for POJOs - BeanDeployer)
      2) ClassLoading deployer (as now or replaced with OSGi style)
      3) Component Deployer (for POJOs KernelDeploymentDeployer)
      4) Scoping Deployer (NEW looks at BeanMetaData and creates ScopedKernel)
      5) Real Deployer (as now BeanMetaDataDeployer - but deploys into ScopedKernel)

      This gives a cleaner api and probably makes it easier to override scoping rules.

      The downside is that you don't get scoping out of the box, you either
      have to use the deployers or write your own scoping config code.

        • 1. Re: Automatic Scoped Kernels - A good idea
          Ales Justin Master

           

          "adrian@jboss.org" wrote:

          For ease of use it probably is, but making it work is requiring too many hacks

          Ok, moving Controller looks kind of hackih, but it is used transparently regarding previous code.

          "adrian@jboss.org" wrote:

          and I have a feeling that Ales is doing it wrong anyway or has at least
          misunderstood part of it (Given some of the problems he is reporting).

          My problems are mainly from missing API point of view - UID name, ScopeKey as param, AOP scoping domain, ...
          Or which part you think is really misunderstood?

          "adrian@jboss.org" wrote:

          The alternate approach would be to move the scoping of kernels to the deployers.
          i.e. The MC can support scoped kernels but you have to use an api
          to configure them.

          The deployment chain would then look something like:
          1) Parsing as now (for POJOs - BeanDeployer)
          2) ClassLoading deployer (as now or replaced with OSGi style)
          3) Component Deployer (for POJOs KernelDeploymentDeployer)
          4) Scoping Deployer (NEW looks at BeanMetaData and creates ScopedKernel)
          5) Real Deployer (as now BeanMetaDataDeployer - but deploys into ScopedKernel)

          This gives a cleaner api and probably makes it easier to override scoping rules.

          The downside is that you don't get scoping out of the box, you either
          have to use the deployers or write your own scoping config code.

          We can probably support both.
          Just need to work on the use cases of current impl - something we said before I went and hacked this initial code.

          • 2. Re: Automatic Scoped Kernels - A good idea
            Adrian Brock Master

             

            "alesj" wrote:

            Or which part you think is really misunderstood?


            It was something you said either last week or the previous week
            about having duplicates and I responded that I didn't understand
            the issue since it should be impossible to have duplicates in the same scope.

            I'm also not sure whether you understood the issue with the classloader
            creating a dependency on itself?

            ClassLoader (as bean) -> scope annotations creates scope -> requires classloader (itself)

            There's also some other subtle issues about how we expect to use the scopes.
            e.g. A bean in a kernel deployment might have the full scope:

            Application=myapp.ear
            Deployment=mybeans.jar
            Class=MyBean.class
            Instance=BeanName

            But you aren't going to create a ScopedKernel at the Intance level or class level.
            The natural level for the scope would be at the Application/Deployment pair.

            This latter issue is much easier to deal with from the deployers
            (which understand deployment structure) than it is from the automatic scope generation
            that we are prototyping.

            I also think there will be use cases where people want to assign a scope
            to a bean (or MBean) for the purposes of the MetaData overrides but don't
            want a full scoped kernel for their deployment?

            And we still need to address the issue I raised with "exporting" beans
            into global scope (if that really is a use case ?).

            Basically, like I said at the beginning, although we are building a mechanism
            to do something called scoped kernel, we haven't gone through a requirements
            gathering stage to see whether it meets the real need(s).

            This makes me worried. :-)

            I'm happy that the controller api should support scoped kernels (the implementation side)
            but I'm not so sure on the "policy" side that the way we are creating
            assigning contexts to scope is correct.

            • 3. Re: Automatic Scoped Kernels - A good idea
              Scott Stark Master

              I would like to see the scoped kernel notion overviewed in the context of the existing architecture as it seems its too much of a piecewise prototype at this point. The main sticking points are namespaces, cross kernel dependencies, and relation to type systems/class loaders.

              • 4. Re: Automatic Scoped Kernels - A good idea
                Adrian Brock Master

                 

                "scott.stark@jboss.org" wrote:
                I would like to see the scoped kernel notion overviewed in the context of the existing architecture as it seems its too much of a piecewise prototype at this point. The main sticking points are namespaces, cross kernel dependencies, and relation to type systems/class loaders.



                And AOP Domains (scoped AOP metadata/aspect manager).