4 Replies Latest reply on Oct 27, 2006 9:12 AM by Adrian Brock

    To merge or not to merge?

    Adrian Brock Master

      I've been thinking about this merging of metadata
      between ejb-jar.xml and jboss.xml and I'm not sure we
      actually want to do this?

      The main reason is that doing so, loses the information
      on where the metadata came from.

      1) You cannot take the metadata and turn it back into the xml files.
      2) You don't know where to direct the user about where to fix something

      A simple example is jndi-name in jboss.xml which now has a
      corresponding mapped-name in ejb-jar.xml for EJB3

      Making these the same property would lose which file it came from.

      Given that I want to extend jboss.xml so you can override
      "everything" this doesn't look like a good solution.

      A better solution would be to make it delegate,
      like the following pseudo code.

      class DelegateBeanMetaData
      {
       String getJndiName()
       {
       String result = jbossXML.getJndiName();
       if (result == null)
       return ejbJarXML.getMappedName();
       }
      }
      


      In fact, with the org.jboss.metaData stuff
      it would be trivial to implement this provided the metadata
      is split up enough.

      You just need two MetaDataContexts one for jboss.xml
      and one for ejb-jar.xml

      Then the query becomes:
      JndiBinding binding = MetaData.getMetaData(JndiBinding.class);

        • 1. Re: To merge or not to merge?
          Scott Stark Master

          This is what I was referring to previously about a unified api for traversing/merging the various scopes of data. This also intersects with the discussion on how overlapping annotation collections are merged. There is a tradeoff between having a framework that generally can build up something like a JndiBinding vs having to write the merge logic in terms of delgating accessors.

          Given n scopes of data of types T1...Tn, and a unfied type T (which usually would be amongst T1...Tn I would expect), the ideal thing would be to have the framework piece together the type instances so that T.x was a merge ot the T1...Tn sources of the property x. How to write this without significat restrictions on how the types relates seems non-trivial at this point.

          • 2. Re: To merge or not to merge?
            Adrian Brock Master

            But I think we are talking about different things, at least from
            my understanding of your original post.

            There is a need to merge/hide/override at runtime and this
            depends upon the type of metadata (it also includes having the
            ability to query where the data came from).

            The full normalized view should be maintained elsewhere.

            When I talk about merging I'm talking about giving the runtime view,
            e.g. getting all the resource-refs for a bean (from all levels).

            • 3. Re: To merge or not to merge?
              Scott Stark Master

               

              "adrian@jboss.org" wrote:
              But I think we are talking about different things, at least from
              my understanding of your original post.

              There is a need to merge/hide/override at runtime and this
              depends upon the type of metadata (it also includes having the
              ability to query where the data came from).

              Argreed, but runtime usage vs asking where runtime T.x actually came from seem like two different uses of the composite metadata for the type T. One way to get the runtime view would be to collapse the levels into an instance T. Another would be a T facade over delegating accessors/iterators that do the right thing for each property x of T.

              "adrian@jboss.org" wrote:

              The full normalized view should be maintained elsewhere.

              I'm not following what you mean by normalized view?

              "adrian@jboss.org" wrote:

              When I talk about merging I'm talking about giving the runtime view,
              e.g. getting all the resource-refs for a bean (from all levels).

              Yes, that is what I would consider as merging as well.


              • 4. Re: To merge or not to merge?
                Adrian Brock Master

                 

                "scott.stark@jboss.org" wrote:

                "adrian@jboss.org" wrote:

                The full normalized view should be maintained elsewhere.

                I'm not following what you mean by normalized view?


                The normalized view is all the information coupled with where it is defined
                not the merged/denormalized view.

                i.e. at runtime you say
                "What are the resources for this ejb?"
                "What is the transaction timeout for this ejb method?"
                which comes from the denormalized view, i.e. you get all the resources
                that are relevant for the ejb, or the transaction timeout for that context
                (regardless of where it is defined).

                Elsewhere you use the normalized view, so the responses will be
                different:
                "What are the resources for this ejb?"
                Will only include those actually defined on the ejb not those
                defined at e.g. deployment level for which you would need to ask
                the normalized view:
                "What are the resources for this deployment?"

                Similarly for the transaction timeout. The denormalized should
                always give you an answer (even if it is just the timeout defined at
                server/domain level).
                The normalized view will only give you an answer if something
                is defined against that ejb method.

                In the normalized view you can ask:
                "Is there a transaction timeout for this ejb method?"
                "Is there a transaction timeout for this ejb?"
                "Is there a transaction timeout for this deployment?"
                "Is there a transaction timeout for this server?"
                etc.