1 Reply Latest reply on Jul 19, 2009 10:26 PM by Ales Justin

    JBKERNEL-12 - Scoped Deployments

    Marius Bogoevici Expert

      I started looking at Scoped Deployments as part of some work surrounding the Spring Deployer. To wit, this means allowing Spring-instantiated beans to be registered as MC beans, essentially hiding their Spring nature from the rest of the application, and then allowing them to be injected in other application-server deployed objects, most notably EJBs. One desirable behaviour would be to allow for deploying these beans in a distinct scope, so that they don't start polluting the whole MC bean namespace. This would be useful in the case of EAR deployments, where the Spring-related beans would be visible only for the current EAR, but to nobody else.

      The way I am seeing the scenario working is this:

      1) Every Deployment could get an associated ScopedKernelController (one ScopeKey per Deployment).
      2) A Deployer (AbstractRealDeployer) could have access to this Controller and could deploy/register beans into it
      3) This way, deployers that are supposed to create instances through a third-party managed process (such as Spring AppContext bootstrapping, but this is really a particular case) can register their own MC beans, and there is a certain degree of isolation between the different deployments.

      Now, one thing that I was trying to figure out was how much of this is currently supported by the current implementation, and how much is still there to be done. So, the beginning question is, what are the current thoughts regarding the Scoped Deployments feature, and if there is a list of outstanding TODOs?

      As much as I could figure out from the current implementation, there is the possibility of deploying individual beans with scoping information, provided that the appropriate annotations are added on the metadata, as well as looking them up via the ScopeKeyLookupStrategy. However, there is no generic "deploy in XYZ scope" operation or "get the Controller corresponding to the XYZ scope", or "get Bean from XYZ scope". As well, every deployment gets some scope associated with it, but I can't see this being used in any practical fashion.

      Also, while injection works properly with scoping (i.e. beans will be injected into other beans only if found in the appropriate scope), consuming scoped beans is somehow inconsistent, in that getBean("someBean") called on a Kernel will return the first encountered bean with a given name, defined in the global Kernel controller, or any of its children. If there are multiple beans with the same name defined in the Kernel, in different scopes, an arbitrary bean (first encountered) is chosen and returned.

      Again, what I am looking here is:
      a) some confirmation that things work in the way I described them (or some correction if they aren't), since there is no actual documentation to accompany the code;
      b) some input on the what the current thinking is wrt Scoped Deployments, and the action items that are currently known as necessary (especially in the light of JBKERNEL-12 being still open)
      c) some input regarding the action items necessary this context. For now, what I think it is needed is:
      - on the MC side, allow for a more streamlined "deploy in context" API (essentially wrapping the existing scoping features)
      - on the jboss-deployers side, make sure that every Deployment gets an associated ScopedKernelController and that this ScopedKernelController is available at deployment time
      - all MC-registered beans created by a deployment are created in the Scope of the Deployment
      - Kernel-aware beans that live in a particular deployment context can have access to the Controller that corresponds to their particular scope and can consume other MC beans (if they are visible from that particular scope)

      Thanks for not giving up on reading this already ;) and I am looking forward to your comments,
      Marius

        • 1. Re: JBKERNEL-12 - Scoped Deployments
          Ales Justin Master

           

          "marius.bogoevici" wrote:

          So, the beginning question is, what are the current thoughts regarding the Scoped Deployments feature, and if there is a list of outstanding TODOs?

          There are currently no exact thoughts on the scoped deployment.
          Hence this discussion is very welcome.

          The current scoped *kernels* are initial prototype of what can be done,
          at least a simple hierarchy based lookup and registry is there.
          But of course it is missing a lot of proper API, to be really useful.

          Although I wouldn't limit the scoping to plain parent-child lookup,
          I always had in mind a more peer model, a plane graph - hence GraphController.

          "marius.bogoevici" wrote:

          However, there is no generic "deploy in XYZ scope"

          Not yet, but there should be one, once we properly discuss this.

          "marius.bogoevici" wrote:

          operation or "get the Controller corresponding to the XYZ scope",

          Currently scoping is more an impl detail,
          once we have proper API this should be part of GraphController.

          "marius.bogoevici" wrote:

          or "get Bean from XYZ scope".

          You actually have this with @Search (which is deprecated; was initial impl)
          and something a member of the community contributed - moving this search notion into inject; see its search attribute.

          "marius.bogoevici" wrote:

          As well, every deployment gets some scope associated with it, but I can't see this being used in any practical fashion.

          Not yet, but I think this is the right way to go, and we'll simply re-use this.

          "marius.bogoevici" wrote:

          Also, while injection works properly with scoping (i.e. beans will be injected into other beans only if found in the appropriate scope), consuming scoped beans is somehow inconsistent, in that getBean("someBean") called on a Kernel will return the first encountered bean with a given name, defined in the global Kernel controller, or any of its children. If there are multiple beans with the same name defined in the Kernel, in different scopes, an arbitrary bean (first encountered) is chosen and returned.

          That was one of the reasons I pushed @Search in, to have a consistent / deterministic behavior.
          But this is actually a common problem with any hierarchy/graph lookup; see classloading. ;-)

          "marius.bogoevici" wrote:

          - all MC-registered beans created by a deployment are created in the Scope of the Deployment

          They should only be put into deployment's scope if this is explicitly defined.
          Otherwise it should go into top level / main / global (depending on the structure) scope.
          Or we will break or had to hack too many things.

          To sum things up, I think your understanding of the current code is OK.
          I see we also agree on the need for proper API, on Deployers and Kernel side.
          My guess is we should just play a bit with this, prototype around existing working stuff,
          and see what would be the best way to extend this into some useful feature set.

          e.g. add new scoping info metadata into current pojo, mbean metadata
          * proper elements in KernelDeployment/BeanMetaData or ServiceDeployment/ServiceMetaData
          * external new descriptors that setup proper scoping
          * re-check PolicyMetaData

          First impression is that this would't take much work,
          adding a few new deployers, and modifying BeanMetaDataDeployer to consider this new info on top of GraphController.

          I guess hidding the actual scoping impl under more generic (peer) model would be more work.
          And it's really a question if we should do that, as mostly such lookups are expected to be hierarchical.