12 Replies Latest reply on May 15, 2006 9:06 AM by Kabir Khan

    JBAOP-91 - Annotations

    Adrian Brock Master

      This is the first of a few threads I'm going to start so we can
      create a more detailed roadmap for what is required in the
      JBoss MC/AOP integration.
      i.e. there should be more detailed tasks within JIRA.

      I'll start with the hardest one. :-)
      I don't expect all of this to get done for JBoss MC-2.0.0M1

      This thread is about annotations.
      http://jira.jboss.com/jira/browse/JBAOP-91

      Currently there are 5 sources of annotations:

      * The Java class file, i.e. put there by the compiler
      * Specifying an annotation in some -aop.xml
      * Specifying an annotation in a jboss mc deployment instance override
      * The scoped MetaData repository
      * annotationc (are we keeping this now we have JBoss Retro?)

      I think there are 5 implementations of the annotation stuff, some share
      implementation details, others don't.
      * Javassist (javassist.bytecode.annotation.AnnotationImpl)
      * AOP
      * JBoss Retro (uses Javassist)
      * ClassInfo in the container project (not currently used by the MC/AOP integration)
      * MetaData Repository

      I think Hibernate has some stuff as well?

      Issues:
      1) Single model

      We need a single model for this stuff.
      The biggest issue is that the full solution requires an understanding
      of the classloading model:
      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77746
      http://jira.jboss.com/jira/browse/JBMICROCONT-31
      I don't expect this to get done for 2.0.0M1

      2) Tests

      We need tests of defining annotations in each source.
      This includes deployment time annotations that for example
      add introductions, but also runtime annotations (see 3 below)

      3) MetaData repository

      Part of the metadata repository is to be able to override annotations
      at the request/thread level. e.g. override some configuration option
      like transaction timeout for a particular request or thread.

      There are no current tests for this.

      I couldn't find the original discussion on this
      (there are too many threads on the metadata repository :-),
      but this obviously requires some extra meta-annotation. e.g. the
      security-domain annotation should only be overridable at deployment time,
      not by the client code invoking the service. :-)

      Additionally, it should be possible for a remote client to do this
      override with the annotations getting marshalled with the
      remote request and used on the server.

      4) The Microcontainer needs extra metadata so it can override
      field, constructor, method, parameter, etc. annotations for an instance.
      I don't know what support aop has already for this?
      Again these need testing.

        • 1. Re: JBAOP-91 - Annotations
          Kabir Khan Master

          I will need to take a better look at the JBossRetro stuff to see if we can get rid of annotationc, my initial impressions are good though since annotationc using javadoc does not support things like parameter annotations.


          I can certainly get cracking on number 3 and 4.

          4) The Microcontainer needs extra metadata so it can override
          field, constructor, method, parameter, etc. annotations for an instance.
          I don't know what support aop has already for this?
          Again these need testing.
          


          AOP (using the domain that is created by the proxy per class and per instance) should support overriding of annotations at all levels. Both by using the advisor metadata repository, and the "native" annotation overrides currently used by things like EJB3. I will test this though. Only property (i.e. getter/setter method) and class annotations are currently definable via the bean.xml, so I assume that I should add something to this. Since we are talking about metadata for things like the constructors, the only way I see that being useful unless the class has been AOP woven is if we add interception/create a ConstructorInvocation when creating the bean instance that we pass into the ProxyFactory?

          Also, the proxies do not support field interception, so again I guess that the metadata for these is only relevant when the target instance is aop woven?

          • 2. Re: JBAOP-91 - Annotations
            Adrian Brock Master

            The reason for starting these discussion is to recap what has
            been discussed before in one place and work out what still needs doing.

            I'm doing this so we can load the TODOs into JIRA
            such that others have visibility on the detailed tasks and the progress.

            e.g. something like this:
            http://jira.jboss.com/jira/browse/JBAS-1421

            • 3. Re: JBAOP-91 - Annotations
              Adrian Brock Master

               

              "kabir.khan@jboss.com" wrote:

              AOP (using the domain that is created by the proxy per class and per instance) should support overriding of annotations at all levels. Both by using the advisor metadata repository, and the "native" annotation overrides currently used by things like EJB3. I will test this though. Only property (i.e. getter/setter method) and class annotations are currently definable via the bean.xml, so I assume that I should add something to this. Since we are talking about metadata for things like the constructors, the only way I see that being useful unless the class has been AOP woven is if we add interception/create a ConstructorInvocation when creating the bean instance that we pass into the ProxyFactory?

              Also, the proxies do not support field interception, so again I guess that the metadata for these is only relevant when the target instance is aop woven?


              This is really orthogonal to the proxy processing.
              The proxy is there such that people can do the basic AOP stuff
              without installing AOP into the classloader.

              If people want to do complicated things like field interception
              then they need full blown AOP.

              The idea is that it should be possible to do something like:
              <bean ...>
               <method name="doSomething">
               <annotation name="org.jboss.tm.TransactionTimeout">200</annotation>
               </method>
              ...
              


              This is currently missing for constructors and methods (and their parameters). That is unless it is the constructor defined in the bean.xml
              or it is a lifecycle method (create, start, stop, destroy).

              It is also missing for fields that don't have a getter/setter pair.
              But that should be resolved when I expand the properties processing
              to include fields and alternate methods to the standard get/set pair.

              Obviously this needs some work in the MC metadata before
              the MetaData Repository integration can process these.

              For now, you should be able to test it in the AOP layer
              by loading directly into the repository?

              • 4. Re: JBAOP-91 - Annotations
                Adrian Brock Master

                 

                "kabir.khan@jboss.com" wrote:

                I can certainly get cracking on number 3 and 4.


                I think (2) is the most important.
                Using one of my laws of programming,
                "if it ain't tested, it doesn't work".

                Adding more features when the more foundational stuff isn't
                properly tested will just make it harder to understand where a problem lies.

                • 5. Re: JBAOP-91 - Annotations
                  Adrian Brock Master

                   

                  "adrian@jboss.org" wrote:
                  The reason for starting these discussion is to recap what has
                  been discussed before in one place and work out what still needs doing.

                  I'm doing this so we can load the TODOs into JIRA
                  such that others have visibility on the detailed tasks and the progress.

                  e.g. something like this:
                  http://jira.jboss.com/jira/browse/JBAS-1421


                  I'm going to work my way through from the JBossMC side.
                  Kabir when you get back next week can you start from the AOP side?
                  I think I've started summary discussions for all the major topics?

                  • 6. Re: JBAOP-91 - Annotations
                    Scott Stark Master

                     

                    "adrian@jboss.org" wrote:

                    * annotationc (are we keeping this now we have JBoss Retro?)

                    The javadoc based annotationc stuff I really don't want to keep around. I asssume that the annotation compiler is used for the jboss-aop.xml expressions as well however, and we could have a java5 annotation that describes a aop expression that is compiled to create an annotation expression.

                    • 7. Re: JBAOP-91 - Annotations
                      Scott Stark Master

                       

                      "adrian@jboss.org" wrote:

                      1) Single model

                      We need a single model for this stuff.
                      The biggest issue is that the full solution requires an understanding
                      of the classloading model:
                      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77746
                      http://jira.jboss.com/jira/browse/JBMICROCONT-31


                      Are we going to base the class loader on the vfs abstration, or is this going to be an abstraction that should not be exposed at least at some facade?

                      In terms of class loader issues, we still have much to work out from a generalization of the unified class loader into an osgi bundle/jsr277 notion where better control over class scope/order is controlled to support conflicting jars/patches better than we can today.

                      There is also the notion of hot swapping. This has come up in the context of trying to allow for finer grained redployments (an single ejb in an ear).


                      • 8. Re: JBAOP-91 - Annotations
                        Scott Stark Master

                         

                        "adrian@jboss.org" wrote:

                        3) MetaData repository

                        Part of the metadata repository is to be able to override annotations
                        at the request/thread level. e.g. override some configuration option
                        like transaction timeout for a particular request or thread.

                        There are no current tests for this.

                        I couldn't find the original discussion on this
                        (there are too many threads on the metadata repository :-),
                        but this obviously requires some extra meta-annotation. e.g. the
                        security-domain annotation should only be overridable at deployment time,
                        not by the client code invoking the service. :-)

                        Additionally, it should be possible for a remote client to do this
                        override with the annotations getting marshalled with the
                        remote request and used on the server.


                        In terms of the repository usage for annotations, there is also the notion of being able to cache/precompile a collection of annotations from class, descriptors (any deployment static info) to create a fast deployment. I'm thinking that an aspect in the VDF detects such a cache and loads this into the repository deployment level. The issue is making sure that the ordering of metadata is consistent so that there is no confusion over what should be applied.

                        • 9. Re: JBAOP-91 - Annotations
                          Bill Burke Master

                          The QDOX stuff should be retired, yes. But that is but a small part of the annotation compiler. The expression parsing and such is needed for annotation overloads and annotation introductions (as you mentioned).

                          • 10. Re: JBAOP-91 - Annotations
                            Bill Burke Master

                             

                            "scott.stark@jboss.org" wrote:
                            "adrian@jboss.org" wrote:

                            3) MetaData repository

                            Part of the metadata repository is to be able to override annotations
                            at the request/thread level. e.g. override some configuration option
                            like transaction timeout for a particular request or thread.

                            There are no current tests for this.

                            I couldn't find the original discussion on this
                            (there are too many threads on the metadata repository :-),
                            but this obviously requires some extra meta-annotation. e.g. the
                            security-domain annotation should only be overridable at deployment time,
                            not by the client code invoking the service. :-)

                            Additionally, it should be possible for a remote client to do this
                            override with the annotations getting marshalled with the
                            remote request and used on the server.


                            In terms of the repository usage for annotations, there is also the notion of being able to cache/precompile a collection of annotations from class, descriptors (any deployment static info) to create a fast deployment. I'm thinking that an aspect in the VDF detects such a cache and loads this into the repository deployment level. The issue is making sure that the ordering of metadata is consistent so that there is no confusion over what should be applied.


                            What I think we should do is define a specific usecase and build a prototype to it. This is what I'm actually doing now. I'll post about it on the pojo server forum...

                            • 11. Re: JBAOP-91 - Annotations
                              Kabir Khan Master

                              I've added tests for annotation overrides from jboss-aop.xml

                              • 12. Re: JBAOP-91 - Annotations
                                Kabir Khan Master

                                I've added tests for annotation overrides from jboss-aop.xml