1 2 Previous Next 27 Replies Latest reply on Mar 10, 2006 7:13 AM by kabirkhan

    AOP/MC Next Step

      The proxy is looking really good now. A lot better than my DP prototype :-)
      I've still got to look at Mixins and other ways to break it. :-)

      Can this be moved to AOP rather than Aspects?
      It will probably mean rewriting some of the tests to not depend upon jboss-j2ee classes?

      The next step is the typed metadata integration:
      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73653

        • 1. Re: AOP/MC Next Step
          kabirkhan

          I;ve had a look at the metadata stuff. Can you please explain what the "MetaDataContext" is as outlined in the other thread?

          • 2. Re: AOP/MC Next Step

            It is the object that tells you what you are searching for and where to start searching.

            I think in Scott's prototype it is called "Key"

            public interface KernelRepository
            {
             public Object getMetaData(Key key);
            ...
            


            I'd prefer it if this more implicit, i.e. the context holds a link to the repository
            and the thing you were searching for is just the annotation class name
            with an interface like AnnotatedElement from the JDK.

            That way the Advisor/joinpoint just needs a mechanism to hold the context
            initialized either
            * implicity based on deployment config
            * a setter method on the advisor
            * a parameter on the proxy factory methods

            e.g.
            class Advisor
            {
             setMetaDataContext(MetaDataContext ctx);
            }
            
            // Interceptor usage
            public Object invoke(Invocation inv)
            {
             MyAnnotation x = inv.getAnnotation(MyAnnotation.class);
            }
            
            Effectively Maps to
            MetaDataContext ctx = inv.getAdvisor().getMetaDataContext();
            MyAnnotation x = ctx.getAnnotation(MyAnnotation.class);
            
            With the later in Scott's prototype mapping to:
            KernelRepository rep = ctx.getRepository();
            Map scope = ctx.getScope();
            Key key = new Key(MyAnnotation.class, scope);
            return rep.getMetaData(key);
            


            • 3. Re: AOP/MC Next Step

              The thing I don't see in Scott's prototype is the ability to retrieve/manage
              the joinpoint metadata, e.g. changing method transaction timeouts via the repository.

              This also needs be done as a part of the invocation.getAnnotation(...)

              • 4. Re: AOP/MC Next Step

                In case the requirement is not clear, the idea is that
                code will go to the metadata repository to retrieve annotations
                rather than asking the classes directly.

                The most important consumer being the advices.

                This metadata repository can be populated at different levels,
                e.g. deployment, server, cluster

                The simplest possible metadata repository implementation
                (e.g. for simple standalone usage) is to just proxy requests to the reflection api.

                • 5. Re: AOP/MC Next Step
                  kabirkhan

                  I'm still not totally with you. I get the basic idea of what happens when the invocation needs to use the repository. I'm missing the bit of who owns the repository.

                  Will there eventually be one repository installed in the Microcontainer at startup? If so will this (i.e. which MetaDataCombiners exist) be managed by the KernelConfig?

                  Or do you see it as being created as a bean, and somehow injected into the advisors of the advised classes?

                  Or am I missing the point and the repository is actually set up somewhere else?

                  Once I have a reference to the repository it should be possible to pass this in to the created advisor via the proxy factory.

                  • 6. Re: AOP/MC Next Step
                    starksm64

                    The repository will be configured as a bean, and there will likely be repository aspects that associate MetaDataCombiner/MetaDataLoader as well as the default starting scope starting point/Key.

                    The default MetaDataCombiners/MetaDataLoaders would also be configured at the mc bean level to define the namespace used for metadata from the kernel.

                    This is how I see the repository used.

                    • 7. Re: AOP/MC Next Step

                      That is correct. The AOP layer doesn't really need to worry about how it
                      gets the repository reference, only the mechanism to use it once it is injected.

                      Once we have the basic mechanism in place, we will likely want to look
                      at how this relates to things like AOP domains in terms of contextual configuration.

                      • 8. Re: AOP/MC Next Step

                        The basic flow (I'll write a test next week)
                        is that the MC will instantiate the repository and load it with application context data
                        (beyond what is already defined in the class annotations).

                        The advisor will then be injected with the MetaDataContext (a link into the relevant
                        part of the repository) which can be used by the advices to retrieve this metadata.

                        • 9. Re: AOP/MC Next Step
                          kabirkhan

                          I've got the bulk of this fleshed out, and I am reworking your JMXDecoratedTestCase to use this.

                          I've got an AOP version of KernelRegistry set up to do some special handling if the data we are setting is an instance of AnnotationMetaData. If it is I use Bill's annotation proxy to implement the interface.

                          The problems I am having (mainly cause I'm afraid to change the API) are:

                          I am setting up DescribeAction to define the metadata in the repository as defined here:
                          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76685
                          The repository is installed as a bean via the config xml, but when using the repository from DescribeAction I am currently hardcoding the name of the repository to be used.

                          I've got AOPConstructorJoinpoint set up to create the MetadataContext and inject into the advisor. However, there is no way to get the name of the bean that should be installed, something which would be useful for construction of the key. Again, since I have no access to the kernel from AOPConstructorJoinpoint I have a pretty nasty hack in place to get hold of the repository (basically the AOPKernelRegistry is a singleton with a static factory method). I would like for the KernelControllerContext to be propagated to the joinpoints if possible. Not sure if that fits in with your plans?





                          • 10. Re: AOP/MC Next Step

                            I've been looking through this today.

                            Basically I want to move the AOPClassPool stuff to container and use it
                            for the javassist ClassInfo.

                            The AOPClassPool doesn't look to have any dependency on AOP
                            other than the link to the aspect manager which holds the classloaders
                            such that it can be told when classloaders are undeployed.

                            It will be trivial to move this into a new data structure in container
                            and make the AspectManager talk with the new datastructure.

                            Then we need to link it to the metadata repository such that the MC
                            can add instance annotations.

                            I had a quick look at Bill's annotation stuff which looks like a clone of
                            something already in javassist? Except it has links into the xml deployment layer.

                            We need this annotation stuff in the ClassInfo/metadata layer anyway for
                            the retro style processing and annotations set in xml policy config or metadata loaders.

                            • 11. Re: AOP/MC Next Step

                               

                              "kabir.khan@jboss.com" wrote:
                              I've got the bulk of this fleshed out, and I am reworking your JMXDecoratedTestCase to use this.


                              Good


                              I've got an AOP version of KernelRegistry set up to do some special handling if the data we are setting is an instance of AnnotationMetaData. If it is I use Bill's annotation proxy to implement the interface.

                              The problems I am having (mainly cause I'm afraid to change the API) are:

                              I am setting up DescribeAction to define the metadata in the repository as defined here:
                              http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76685
                              The repository is installed as a bean via the config xml, but when using the repository from DescribeAction I am currently hardcoding the name of the repository to be used.

                              I've got AOPConstructorJoinpoint set up to create the MetadataContext and inject into the advisor. However, there is no way to get the name of the bean that should be installed, something which would be useful for construction of the key. Again, since I have no access to the kernel from AOPConstructorJoinpoint I have a pretty nasty hack in place to get hold of the repository (basically the AOPKernelRegistry is a singleton with a static factory method). I would like for the KernelControllerContext to be propagated to the joinpoints if possible. Not sure if that fits in with your plans?


                              Ignoring the horrible API which I've still got to fix, I'm actually thinking of not
                              overriding the annotations via the ClassInfo/ClassAdapter and instead
                              the MC would just install the annotations as instance level metadata in the
                              metadata repository.
                              This should work provided AOP is looking at instance level annotations when
                              it is applying the pointcuts.

                              So the MC/AOP annotation integration would basically boil down
                              to something like the MC injecting the metadata context into the ClassAdapter
                              instance ready for AOP to pick and use when it creates the instance.

                              I'm not sure how easy this is for you at the AOP level?
                              e.g. can you easily understand that when instance level annotations exist
                              you might need to create a proxy if the annotation creates an introduction?

                              • 12. Re: AOP/MC Next Step

                                 

                                "kabir.khan@jboss.com" wrote:
                                (basically the AOPKernelRegistry is a singleton with a static factory method).


                                You shouldn't need to do anything with the MC registry or the metadata registry.
                                You should be using the metadata context (which you get passed) and the classinfo
                                since you are only interested in the annotations and the joinpoints.

                                • 13. Re: AOP/MC Next Step

                                  Finally, I want to make sure we have minimal disruption to AOP.
                                  i.e. If somebody is using AOP without the MC/metadata repository.

                                  So we need to make sure the moving of the AOPClassPool to container
                                  and other changes doesn't pull in lots of dependencies.

                                  I'm wondering how we can abstract the MetaData context, etc. such that you
                                  could just use a simple version that maps directly onto the old class/ctclass stuff
                                  in the joinpoint parsing, rather than introducing a third mechanism.

                                  e.g. the joinpoint parsing already has Method and CtMethod variations.
                                  It would make more sense to me to have a single api that could be these
                                  or it could be the metadata repository for annotations.

                                  A bit like what I have done with ClassInfo where it can come from plain reflection
                                  or it can come from javassist.

                                  • 14. Re: AOP/MC Next Step
                                    kabirkhan

                                    I've worked around the problems I mentioned by moving construction of the MetaDataContext further into the kernel, and initialising it in KernelControllerContextActions. AFAICT the main thing I have done to any API which isn't considered stable, is adding KernelControllerContext.get/setMetaDataContext() methods. There may well be a better home for this, so please take a look.

                                    We should probably make the exisiting Invocation.resolveAnnotation() methods check with the repository first before doing what it is already doing now? Or maybe I should move this into the Advisor, so that the matchers use the same interface as now when determining if something should be advised. The repository (my stuff anyway) currently only handles class-level annotations, we need a way to apply this to methods/constructors/fields.

                                    There is no way to know if an annotation will introduce introductions yet, so I need to think a bit about that one.

                                    Where (package name) in the container project do you want the ClassPool stuff? I can start looking at moving that over. It would be nice to get the matchers working using ClassInfo to avoid all the duplicate code as well.

                                    1 2 Previous Next