3 Replies Latest reply on Sep 14, 2006 12:48 PM by Scott Stark

    Deployers, ContextData and MangedObjects

    Adrian Brock Master

      I'm nearly ready to merge the new Deployers into MC-VDF-WORK.

      The parts left to do are the ContextData and the ManagedObject.

      There is a little bit of overlap in what these are trying to achieve,
      I think the real distinction comes down to how they are used
      and how they get created.
      I'll call them context attachments or just attachments for short.

      The requirements as I see them are:

      1) The ability to typesafely retrieve data about a context
      (this can be shared between deployers, i.e. one deployer
      creates it for a later stage to use).

      2) The attachment can be non-trivial, e.g. an EJB deployment can
      have many ejbs, can have many resource refs.

      3) The attachment can be predefined by the profile service.
      i.e. rather than using the ejb-jar.xml in the deployment, it
      uses an EJBDeployment.class instance that has already
      been overridden.

      4) I also want to integrate the MetaDataRepository
      (this is not necessary for the initial integration)
      at this level using the Scopes defined in org.jboss.metadata.
      Each deployer is obviously going to have some say
      in defining what scope a deployment or part of a deployment
      belongs to.

      I want to provide a helper mechanism whereby this can be
      done declartively in simple cases, e.g. something like the following
      pseudo code:
      processDeployment(EJBDeployment.class, "ejb-jar.xml", ...);
      where the deployment aspect extends a known parsing mechanism
      like I did for the SimpleSubDeployerSupport.
      It also does all the logic of checking whether the object
      was already passed in.

      The rest of the work will be about defining suitable attachments

      e.g. things like the ENC processing from xml, annotations
      (including the metadata repository) can be handled by sharing
      the same attachments/metadata although the sources are different.

      Finally (this is not necessary for the initial integration),
      I want to investigate whether it makes sense
      to create a first class notion of "sub contexts"
      (of the deployment context) for things
      like EJBs such that certain aspects can act on
      the sub context as well as the main context.
      e.g. The ENC processing would make sense at this level
      where the ENC is constructed per EJB not the whole deployment.

      More concretely, the ENC attachment would be at the subcontext (EJB)
      level for EJB deployments but at the main context for servlets.
      By making the ENC deployer "subcontext aware" it would be invoked
      on each subcontext and look for metadata at that level.

      The alternative to subcontexts is a complicated/abstract
      metadata model and doing iteration internally within the aspect
      (which is likely going to be repeated code/logic that is difficult
      to change and not extensible as others introduce their
      own subcontext model).

      In the original design document for the Microcontainer I called these
      "Subservices" and let them go all the way down to components
      that make up a service, e.g. the pool or cache

        • 1. Re: Deployers, ContextData and MangedObjects
          Scott Stark Master

          As described, I'm not seeing much distinction between a scope and a subcontext. Espcially for the case of the enc handling, this would seem to be more of a metadata scope with the key and scope set at runtime by an enc aspect. For a invocation, the enc aspect queries for the enc context created during deployment starting at the instance level, and finds it at different levels depending on the deployment type.

          Fleshing out simple resusable aspects and associated deployers for things like an enc, security and logging for kernel beans is what we should look at to flesh this out.

          • 2. Re: Deployers, ContextData and MangedObjects
            Adrian Brock Master

            The issue is about is being worked with.

            1) The MetaData scope is bean instance at the lowest level.
            i.e. You can override annotations at the individual instance level,
            but you can also override it at the class or deployment level, etc.

            2) The ENC scope is spec defined, i.e. per EJB or per WEB deployment
            but it is populated from annotations and their xml (or metadata)
            overrides.

            3) The other use of the Scope(Key) is to identify the "subcontext"
            for JSR77, e.g. an EJB, ConnectionFactory, Servlet, etc.

            • 3. Re: Deployers, ContextData and MangedObjects
              Scott Stark Master

              Yes, but these just look like different items in runtime metadata hierarchy. As I see it there is a scope aspect setting up the proper starting point for metadata hierarchy key, and an aspect like enc retrieves the approriate context by looking up this using the key established by the scope aspect.