11 Replies Latest reply on Dec 19, 2007 11:32 AM by bdecoste

    metadata

    bdecoste

      Now that Beta3 is complete, we need to figure out a plan for overhauling ejb3 for the new metadata project. In a nutshell, IMO we need to rip out AnnotationHandler, DecriptorHandler, all uses of resolveAnnotation(), and add runtime methods to the container classes so we aren't hitting the metadata objects all the time. I volunteer, but I need signoff - this is a significant redesign but needs to be done.

        • 1. Re: metadata
          alrubinger

          Also TODO:

          Remove from the EJB3 Deployers scanning for annotations (should already be in the merged object view).

          "bdecoste" wrote:
          and add runtime methods to the container classes so we aren't hitting the metadata objects all the time


          Don't we *want* to be hitting the metadata objects themselves (as opposed to "getAnnotation()")? Then we're always going back to the object view; no need to add annotations to the container just to be looked up later.

          This refactoring will have the added benefit of breaking everything.

          S,
          ALR

          • 2. Re: metadata
            bdecoste

            I think we want to be able to call container.isClustered() instead of going through all of the metadata everytime. So we go through the metadata at deployment and populate the containers. Definitely getting rid of any sense of xml or annotations.

            Yes, it will break everything. I've made this point - the Beta3 testsuite and TCK numbers are meaningless since we need to rewrite so much.

            • 3. Re: metadata
              alrubinger

              I think the merits of adding the metadata abstractions to the Containers are pretty apparent, but I'm concerned with the amount of plumbing code this introduces.

              For every annotation or XML node, we'll have to make corresponding methods which either delegate back to the metadata object model or redirect to our own instance members.

              What are the arguments against bypassing the abstractions and accessing this information directly in the container like:

              container.getJBossAssemblyDescriptorMetaData().getJndiName()


              instead of:

              container.getJndiName()


              Sure, 2) is more elegant, but 1) requires no plumbing/abstractions.

              S,
              ALR

              • 4. Re: metadata
                wolfc

                We need a runtime model of meta data, not just the meta data itself. I don't want to parse or load / analyze classes just to use a piece of meta data.
                So annotations represent our runtime model.

                I also don't want to have a strong dependency on the container to write up new functionality. So if I want a @ReturnNonNull piece of 'meta data' and have an interceptor check that as a post condition on a method's return value, then I don't want to modify the container for that.

                So in the end I think we'll have the getAnnotation methods.

                • 5. Re: metadata
                  bdecoste

                  I've started on replacing Ejb3AnnotationHandler and Ejb3DescriptorHandler with Ejb3MetadataHandler. If we stick with creating annotations from the new metadata, we can leave the container.resolveAnnotation() calls everywhere as they are.

                  I take it from the last comments that the new metadata lacks the ability to recognize and model unexpected annotations (e.g. @ReturnNonNull).

                  I am starting to wonder what the value of the metadata project is exactly if we go this route - if they are parsing all the annotations and xml, creating an object model, and we are taking that object model and turning it back into annotations, how is this better than what we have now? Sounds considerably slower in fact.

                  • 6. Re: metadata
                    wolfc

                    The only reason is the profile service. It can't handle annotations, so it needs meta data.

                    Any major refactoring should really be done in projects/ejb3.

                    • 7. Re: metadata
                      bdecoste

                      That's where I'm doing it - you had mentioned that before.

                      • 8. Re: metadata
                        starksm64

                         

                        "wolfc" wrote:
                        The only reason is the profile service. It can't handle annotations, so it needs meta data.

                        This does not make sense. The profile service handles whatever a deployment can have as an attachment. @ReturnNonNull does not sound any different from @TransactionAttribute as a piece of method metadata. There is nothing that precludes a deployment metadata from using annotations if that is the proper metadata view.

                        The point of the metadata project is that one has to be able to define a metadata complete view such that a management tool can have a model to modify without having to write back to deployment descriptors. You'll have to explain why @ReturnNonNull cannot fit into a components metadata model of its methods.


                        • 9. Re: metadata
                          bdecoste

                          I've hit the first (of probably several) dependencies mavenizing ejb3 for projects/ejb3. We depend on org.jboss.embedded, which is now in jbossas.

                          So, I've got to rip it out of jbossas and create a jboss-embedded project.

                          If there are problems with this, please speak up. I'll post to the AS forum as well. If there are problems, I'm going to be forced to make the metadata changes in Trunk.

                          • 10. Re: metadata
                            wolfc

                            We must not depend on embedded. Stow away the code that violates this somewhere.

                            • 11. Re: metadata
                              bdecoste

                              I did - I removed the embedded tests in projects/ejb3. That was the only dependency on jbossas that I encountered.