2 Replies Latest reply on Sep 18, 2006 5:42 AM by adrian.brock

    MetaData - replacement for MetaDataRepository

      WARNING: This work is currently incomplete so although most of this
      exists, some of the integration points do not.

      This is some work I left incomplete to get on with the JBoss5 work.
      It is now coming into view again wrt the annotation overrides and ENC
      processing.

      See the microcontainer container/org/jboss/metadata
      for the spi and implementation.

        • 1. Re: MetaData - replacement for MetaDataRepository

          The basic idea of the MetaData implementation is to provide
          overrides and additions to the annotations and objects
          for a given scope.

          There are two identities that are related. The identity
          is defined by the scope and how you use it.

          The first identity is the context you are working with
          and is most likely a mutable metadata, the exception being
          when the metadata source is immutable like a class file
          (except via aop which is irrelevant for this discussion).

          Examples contexts would be a deployment, a server, a cluster,
          a subsystem (jca, ejb), a component (an ejb container), a class
          or an object instance.
          Other examples which I'll come to later are threads and transactions.

          For each of these there is a MutableMetaData that lets you
          modify just that context. This will update all the full metadata
          hierarchies that it is a part of see below.

          Example:

          ScopeKey key = new ScopeKey(CommonLevels.DEPLOYMENT_NAME, "mywar.war");
          MutableMetaData mutable = // create it
          mutable.addAnnotation(someAnnotation);
          mutable.addMetaData("someName", someObject);
          repository.addMetaData(key, mutable);
          


          The second form is the hierarchical metadata.
          This is made up of the mutables but with a read only view (MetaData).
          This is what will actually be used at runtime.
          You select the hierarchy using a ScopeKey.

          Example:
          Scope[] scopes = new Scope[]
          {
           new Scope(CommonLevels.INSTANCE_NAME, "MyServlet");
           new Scope(CommonLevels.CLASS_NAME, servletClass.getClass().getName());
           new Scope(CommonLevels.DEPLOYMENT_NAME, "mywar.war");
           new Scope(CommonLevels.APPLICATION_NAME, "myapp.ear");
           // etc.
          }
          ScopeKey key = new ScopeKey(scopes);
          MetaData metaData = repository.getMetaData(key);
          


          Finally, in the later example you will get two extra scopes
          (well actually it should depend upon repository configuration).

          The first is a thread local metadata object, the second
          a transaction metadata object. Both are mutable using
          a private api.

          You can aop adding a "request scope" as well, but that
          it is going to take a while to persuade to Bill and Kabir to do. :-)

          • 2. Re: MetaData - replacement for MetaDataRepository

            The final piece of the puzzle is the metadata stack.

            This is a stack of MetaData maintained by each component
            as requests come in. You can imagine this as a generilzation
            of the thread context classloader behavior.

            The idea is that the contextual MetaData should be able to pass
            under the wire of user interfaces.

            Something like:

            repository.addStack(myMetaData);
            try
            {
             // do stuff
            }
            finally
            {
             repository.popStack(myMetaData);
            }
            


            Later somebody can do:
            MetaData metaData = repository.peek();