1 2 Previous Next 21 Replies Latest reply on Nov 29, 2007 6:58 PM by Anil Saldanha

    metadata simplification

    Scott Stark Master

      Based on today's call, the following is what I'm doing to finalize the metadata:

      1. Have all jboss metadata extend the spec metadata
      2. Remove the merged view accessor methods from the jboss metadata. The jboss metadata is the merged/superset view.
      3. Create a merged utility package for creating a merged jboss view from a spec view and one or more jboss views. The output will be another jboss metadata instance.

        • 1. Re: metadata simplication
          Scott Stark Master

          4. Validate the existing use of NonNullLinkedHashSet parent classes as there are uses where non-unique elements (like container-transaction) are being lost because they are modeled as a set rather than a list.

          • 2. Re: metadata simplication
            Scott Stark Master

            4 is done, and a checkpoint of 1-3 has been committed to trunk for the ejb metadata. Its still broken as the merged behavior is not finished. I created a https://svn.jboss.org/repos/jbossas/projects/metadata/branches/stable/ branch with the pre-trunk code prior to the checkpoint.

            I hope to have the tests working again tomorrow. Hopefully you can do something with this in terms of getting the ejb metadata extensions you need in Carlo.

            • 3. Re: metadata simplication
              Carlo de Wolf Master

              On 3: if we have a merge method with two jboss views, we can merge jboss view, standard jboss view and annotation view by just doing the motions:

              JBossMetaData standardJbossXml = unmarshall
              JBossMetaData jbossXml = unmarshall
              EjbJarMetaData ejbJarXml = unmarshall
              if(!ejbJarXml.isMetaDataComplete())
              {
               JBossMetaData annotationMetaData = .... (creator something)
               merged = Merger.merge(standardJbossXml, annotationMetaData);
              }
              else
              {
               merged = standardJbossXml;
              }
              merged = Merger.merge(merged, ejbJarXml);
              merged = Merger.merge(merged, jbossXml);


              • 4. Re: metadata simplication
                Carlo de Wolf Master

                We're still mixing merging and parsing logic, which to me looks like an unsolvable puzzle.

                What's the function of the override (NamedMetaDataWithDescriptionGroupWithOverride.data)?
                Either it's for holding data from the jboss xml parse or it's for referring to the override. IMHO it can't be both.

                The code now creates a StackOverflow in JBossEnterpriseBean.setDescriptionGroup. (ensureOverride returns a new instance of the same class and calls setDescriptionGroup.)
                I have changed this part, but as long as the above question is unanswered the solution is by definition wrong.

                Another thing is the merge method: the current use of the merge is contradicting the implementation.
                MergeUtil.merge:

                JBossMetaData merged = new JBossMetaData();
                 merged.merge(jboss, spec);
                 merged.setOverridenMetaData(spec);
                 return merged;

                vs for example IdMetaDataImpl:
                public void merge(IdMetaDataImpl merged, IdMetaDataImpl original)
                 {
                ...
                 if (id != null)
                 merged.setId(id);
                 else if (original.id != null)
                 merged.setId(original.id);
                 }

                where merged is the target. I would rather see this as target (as in MergeUtil) and have the following signature:
                interface Mergable<M>
                void merge(M original, M override);

                Or maybe only a one-way merge:
                interface Mergable<M>
                void merge(M override);

                Because the default (non-performant) code is always:
                void merge(M original, M override)
                {
                 merge(original);
                 merge(override);
                }


                • 5. Re: metadata simplication
                  Scott Stark Master

                  The point of having the override is to allow for serializing the data back out to the original source(s).

                  NamedMetaDataWithDescriptionGroupWithOverride is for holding uniquely named jboss.xml data that applies to an override. I was trying various things to get the merged view, and ensureOverride is a hack I don't think should be used.

                  Your right, that merged.merge(...) usage is incorrect relative to the current merge method impls.

                  The standardjboss.xml case is a special case of a partial jboss.xml that is handled by the JBossMetaDataWrapper. I don't think we need another merge to support that.

                  • 6. Re: metadata simplication
                    Carlo de Wolf Master

                    What should JBossMetaData.getEnterpriseBeans() return?
                    Or is that based on whether overriden is set? If not, return original, if so return merged?
                    It sounds doable, but won't we end up with some troublesome logic in the classes?
                    I would rather have a new object graph containing the merged metadata. Both originals (spec & jboss) are then still available (and untouched).

                    • 7. Re: metadata simplication
                      Scott Stark Master

                      JBossMetaData.getEnterpriseBeans() should return a JBossEnterpriseBeansMetaData, which implements IEnterpriseBeansMetaData. For the raw parsing output this should be the jboss.xml contents. To create the merged view we do need to create a new JBossMetaData instance and merge the jboss and spec parse results, so we agree there.

                      In terms of having the override associated with the jboss version of the metadata, its not really needed and could be dropped. I do think we do need the merge logic between the spec and jboss classes in the various classes for ease of maintence. I don't have a strong prefernce for merging into this vs one of the arguments.

                      • 8. Re: metadata simplication
                        Scott Stark Master

                        I guess the main argument for having x.merge(...) merge into x is is that if you don't have jboss a metadata instance to merge you have strange code vs just passing in null:

                         // Merge from empty self into self with spec
                         JBossObject x = new JBossObject();
                         x.merge(x, spec);
                        
                         // Vs, merge spec
                         x.merge(null, spec);
                        



                        • 9. Re: metadata simplication
                          Carlo de Wolf Master

                           

                          "scott.stark@jboss.org" wrote:
                          In terms of having the override associated with the jboss version of the metadata, its not really needed and could be dropped.

                          So we're going for complete inheritance to parse ejb-jar constructs in jboss xml?
                          "scott.stark@jboss.org" wrote:
                          I do think we do need the merge logic between the spec and jboss classes in the various classes for ease of maintence.

                          Agreed, we must have some class hierarchy for merging, so we might as well the classes themselves responsible for that.
                          As soon as we drop override, it should clear up a bit.

                          • 10. Re: metadata simplication
                            Carlo de Wolf Master

                             

                            "scott.stark@jboss.org" wrote:
                            I guess the main argument for having x.merge(...) merge into x is is that if you don't have jboss a metadata instance to merge you have strange code vs just passing in null:

                            If we merge into self, the argument stands. If we merge into a new object graph and there is no spec you would get:
                            jboss.merged(merged, null);


                            As a counter point: the instance merge methods would be more in line with that static ones. Both having the same arguments with a static merge method returning the result and an instance merge method working on this.

                            For me only the merged view is important, so I don't mind what happens to the original objects.

                            What happens when we get another view / annotation view?

                            • 11. Re: metadata simplication
                              Scott Stark Master

                               

                              "wolfc" wrote:

                              As a counter point: the instance merge methods would be more in line with that static ones. Both having the same arguments with a static merge method returning the result and an instance merge method working on this.

                              For me only the merged view is important, so I don't mind what happens to the original objects.

                              What happens when we get another view / annotation view?

                              I don't think that is counter as I'm saying merging into this is a cleaner view, so let's just do that.


                              • 12. Re: metadata simplication
                                Bill Burke Master

                                Geez guys, too many abstractions, too many interfaces, too many classes. Just freakin do it. Its much easier to maintain, to figure out what is going on, and for noobs to contribute if its all brute force. Its parsing XML to create a meta model, its not a phd thesis.

                                • 13. Re: metadata simplication
                                  Bill Burke Master

                                  BTW, puke like this is why I like the DOM approach so much better. XB seems way to inflexible and overbearing most of the time.

                                  • 14. Re: metadata simplication
                                    Scott Stark Master

                                    I just checked in another update that changes the merge around and expands the jboss metadata as a step to simplifying the interfaces/hierarchy. I have not dropped the override holder as yet. Once I get the merge methods in better shape I can look at getting rid of unneeded interfaces/base classes.

                                    1 2 Previous Next