1 2 Previous Next 17 Replies Latest reply on Apr 9, 2009 2:38 AM by Jason Greene

    Improving the process of applying AnnotationPlugins on MC be

    jaikiran pai Master

      While working on improving the EJB3 deployment time https://jira.jboss.org/jira/browse/EJBTHREE-1800 i noticed that MC aggresively scans for annotations on MC beans (we deploy EJB3 containers and EJB3 proxy factories as MC beans) and their methods and fields. MC does this to process these annotations (if present) through various AnnotationPlugins. However, the way its currently done:

      1) Get all plugins
      2) Create a method/field/constructor signature from MethodInfo/FieldInfo/ConstructorInfo
      3) Create ComponentMetaData for these signatures (internally leads to reflection on the classes/methods).
      4) Pass this info to the plugin which *then* checks to see whether it can process the annotation. If it can't then step #2 and #3 go waste

      These steps are repeated when the plugin is being applied (deployment) and once during cleanup (undeployment).

      Profiling the application shows that step#3 turns into a hotspot when the number of beans increases and the number of methods and fields on the beans increases. Also the logs show a lot of these statements :

      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ExternalInstallAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ExternalInstalls
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.SupplysAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Supplys
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.AliasesAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Aliases
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.DemandsAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Demands
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ClassFactoryAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Factory
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.BeanAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Bean
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ExternalUninstallAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ExternalUninstalls
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.DependsAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Depends
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ConstructorParameterAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Constructor
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.StringValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.StringValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.NullValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.NullValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ArrayValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ArrayValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ListValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ListValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.PropertyInstallCallbackAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Install
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ValueFactoryAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ValueFactory
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.MapValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.MapValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.InjectAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Inject
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.SetValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.SetValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.JavaBeanValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.JavaBeanValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.CollectionValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.CollectionValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ThisValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ThisValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.PropertyUninstallCallbackAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Uninstall
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.StringValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.StringValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.NullValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.NullValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ArrayValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ArrayValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ListValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ListValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.PropertyInstallCallbackAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Install
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.ValueFactoryAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.ValueFactory
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.MapValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.MapValue
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.InjectAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Inject
      2009-04-03 16:50:55,256 TRACE [org.jboss.kernel.plugins.annotations.SetValueAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.SetValue
      ...// removed a lot of similar log lines, intentionally
      ...
      ...
      
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.MethodUninstallCallbackAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Uninstall
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.DestroyLifecycleAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Destroy
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.UninstallMethodParameterAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.UninstallMethod
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.FactoryMethodAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.FactoryMethod
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.StopLifecycleAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Stop
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.StartLifecycleAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Start
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.MethodInstallCallbackAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Install
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.CreateLifecycleAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Create
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.InstallMethodParameterAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.InstallMethod
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.MethodUninstallCallbackAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Uninstall
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.DestroyLifecycleAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.Destroy
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.UninstallMethodParameterAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.UninstallMethod
      2009-04-03 16:50:55,261 TRACE [org.jboss.kernel.plugins.annotations.FactoryMethodAnnotationPlugin] (main) No annotation: org.jboss.beans.metadata.api.annotations.FactoryMethod
      


      From what i see in the code (org.jboss.kernel.plugins.annotations.CommonAnnotationAdapter.java), i think there's chance for optimization :

      1) We have all the annotation plugins and hence know which annotations, they can handle
      2) The MethodInfo/ConstructorInfo/FieldInfo, provides a isAnnotationPresent(...) API.
      3) Use this API and compare it against *all the plugins* to filter out only relevant plugins that can process these annotations
      4) Most of the times, most of the methods/fields will have no annotations and hence those methods will get skipped.
      5) After we have a non-empty collection of plugins, we can then go on to create the method/field signatures and the ComponentMetadata

      Here's the patch which i came up with:
      Index: src/main/java/org/jboss/kernel/plugins/annotations/CommonAnnotationAdapter.java
      ===================================================================
      --- src/main/java/org/jboss/kernel/plugins/annotations/CommonAnnotationAdapter.java (revision 86731)
      +++ src/main/java/org/jboss/kernel/plugins/annotations/CommonAnnotationAdapter.java (working copy)
      @@ -25,7 +25,9 @@
       import java.lang.annotation.ElementType;
       import java.lang.annotation.Retention;
       import java.lang.annotation.Target;
      +import java.util.ArrayList;
       import java.util.HashSet;
      +import java.util.List;
       import java.util.Set;
      
       import org.jboss.beans.info.spi.BeanInfo;
      @@ -209,11 +211,36 @@
       {
       for(ConstructorInfo ci : constructors)
       {
      + // let's first find only relevant plugins, through ConstructorInfo, before
      + // creating the constructor signature and retrieving the ComponentMetadata
      + Set<T> relevantConstructorAnnotationPlugins = new HashSet<T>(constructorAnnotationPlugins);
      + for(T plugin : constructorAnnotationPlugins)
      + {
      + // Can this constructor be handled by the plugin?
      + if (!ci.isAnnotationPresent(plugin.getAnnotation()))
      + {
      + // if not then ignore this plugin from processing this constructor
      + if (log.isTraceEnabled())
      + {
      + log.trace("Plugin " + plugin + " with annotation " + plugin.getAnnotation().getName() + " is not relevant for constructor " + ci.toString());
      + }
      + // remove this plugin from list of relevant plugins
      + relevantConstructorAnnotationPlugins.remove(plugin);
      + }
      + }
      + // if there are no plugins which can handle this constructor,
      + // then no use creating a constructor signature and processing further.
      + // Just move on to the next constructor
      + if (relevantConstructorAnnotationPlugins.isEmpty())
      + {
      + continue;
      + }
       Signature cis = new ConstructorSignature(ci);
       MetaData cmdr = retrieval.getComponentMetaData(cis);
       if (cmdr != null)
       {
      - for(T plugin : constructorAnnotationPlugins)
      + // only consider relevant plugins for this constructor
      + for(T plugin : relevantConstructorAnnotationPlugins)
       {
       if (isApplyPhase)
       applyPlugin(plugin, ci, cmdr, handle);
      @@ -238,11 +265,37 @@
       FieldInfo field = pi.getFieldInfo();
       if (field != null)
       {
      + // let's first find only relevant plugins, through FieldInfo, before
      + // creating the field signature and retrieving the ComponentMetadata
      + Set<T> relevantFiledAnnotationPlugins = new HashSet<T>(fieldAnnotationPlugins);
      + for(T plugin : fieldAnnotationPlugins)
      + {
      + // Can this field be handled by the plugin?
      + if (!field.isAnnotationPresent(plugin.getAnnotation()))
      + {
      + // if not then ignore this plugin from processing this field
      + if (log.isTraceEnabled())
      + {
      + log.trace("Plugin " + plugin + " with annotation " + plugin.getAnnotation().getName() + " is not relevant for field " + field.toString());
      + }
      + // remove this plugin from list of relevant plugins
      + relevantFiledAnnotationPlugins.remove(plugin);
      + }
      + }
      + // if there are no plugins which can handle this field,
      + // then no use creating a field signature and processing further.
      + // Just move on to the next field
      + if (relevantFiledAnnotationPlugins.isEmpty())
      + {
      + continue;
      + }
      +
       Signature sis = new FieldSignature(field);
       MetaData cmdr = retrieval.getComponentMetaData(sis);
       if (cmdr != null)
       {
      - for(T plugin : fieldAnnotationPlugins)
      + // only consider the relevant plugins for this field
      + for(T plugin : relevantFiledAnnotationPlugins)
       {
       if (isApplyPhase)
       applyPlugin(plugin, field, cmdr, handle);
      @@ -269,11 +322,37 @@
       {
       if (visitedMethods.contains(mi) == false)
       {
      + // let's first find only relevant plugins, through MethodInfo, before
      + // creating the method signature and retrieving the ComponentMetadata
      + Set<T> relevantMethodAnnotationPlugins = new HashSet<T>(methodAnnotationPlugins);
      + for(T plugin : methodAnnotationPlugins)
      + {
      + // Can this method be handled by the plugin?
      + if (!mi.isAnnotationPresent(plugin.getAnnotation()))
      + {
      + // if not then ignore this plugin from processing this method
      + if (log.isTraceEnabled())
      + {
      + log.trace("Plugin " + plugin + " with annotation " + plugin.getAnnotation().getName() + " is not relevant for method " + mi.toString());
      + }
      + // remove this plugin from list of relevant plugins
      + relevantMethodAnnotationPlugins.remove(plugin);
      + }
      + }
      + // if there are no plugins which can handle this method,
      + // then no use creating a method signature and processing further.
      + // Just move on to the next method
      + if (relevantMethodAnnotationPlugins.isEmpty())
      + {
      + continue;
      + }
      +
       Signature mis = new MethodSignature(mi);
       MetaData cmdr = retrieval.getComponentMetaData(mis);
       if (cmdr != null)
       {
      - for(T plugin : methodAnnotationPlugins)
      + // only consider the relevant plugins for this method
      + for(T plugin : relevantMethodAnnotationPlugins)
       {
       if (isApplyPhase)
       applyPlugin(plugin, mi, cmdr, handle);
      @@ -297,11 +376,36 @@
       {
       if (smi.isStatic() && smi.isPublic())
       {
      + // let's first find only relevant plugins, through MethodInfo, before
      + // creating the method signature and retrieving the ComponentMetadata
      + Set<T> relevantStaticMethodAnnotationPlugins = new HashSet<T>(methodAnnotationPlugins);
      + for(T plugin : methodAnnotationPlugins)
      + {
      + // Can this static method be handled by the plugin?
      + if (!smi.isAnnotationPresent(plugin.getAnnotation()))
      + {
      + // if not then ignore this plugin from processing this method
      + if (log.isTraceEnabled())
      + {
      + log.trace("Plugin " + plugin + " with annotation " + plugin.getAnnotation().getName() + " is not relevant for static method " + smi.toString());
      + }
      + // remove this plugin from list of relevant plugins
      + relevantStaticMethodAnnotationPlugins.remove(plugin);
      + }
      + }
      + // if there are no plugins which can handle this static method,
      + // then no use creating a method signature and processing further.
      + // Just move on to the next static method
      + if (relevantStaticMethodAnnotationPlugins.isEmpty())
      + {
      + continue;
      + }
       Signature mis = new MethodSignature(smi);
       MetaData cmdr = retrieval.getComponentMetaData(mis);
       if (cmdr != null)
       {
      - for(T plugin : methodAnnotationPlugins)
      + // use only relevant plugins
      + for(T plugin : relevantStaticMethodAnnotationPlugins)
       {
       if (isApplyPhase)
       applyPlugin(plugin, smi, cmdr, handle);
      @@ -348,11 +452,36 @@
       return;
      
       visitedMethods.add(method);
      + // let's first find only relevant plugins, through MethodInfo, before
      + // creating the method signature and retrieving the ComponentMetadata
      + Set<T> relevantPropertyAnnotationPlugins = new HashSet<T>(propertyAnnotationPlugins);
      + for(T plugin : propertyAnnotationPlugins)
      + {
      + // Can this getter/setter be handled by the plugin?
      + if (!method.isAnnotationPresent(plugin.getAnnotation()))
      + {
      + // if not then ignore this plugin from processing this getter/setter
      + if (log.isTraceEnabled())
      + {
      + log.trace("Plugin " + plugin + " with annotation " + plugin.getAnnotation().getName() + " is not relevant for getter/setter " + method.toString());
      + }
      + // remove this plugin from list of relevant plugins
      + relevantPropertyAnnotationPlugins.remove(plugin);
      + }
      + }
      + // if there are no plugins which can handle this getter/setter method,
      + // then no use creating a method signature and processing further.
      + if (relevantPropertyAnnotationPlugins.isEmpty())
      + {
      + return;
      + }
      +
       Signature sis = new MethodSignature(method);
       MetaData cmdr = retrieval.getComponentMetaData(sis);
       if (cmdr != null)
       {
      - for(T plugin : propertyAnnotationPlugins)
      + // consider only relevant plugins
      + for(T plugin : relevantPropertyAnnotationPlugins)
       {
       if (isApplyPhase)
       applyPlugin(plugin, pi, cmdr, handle);
      
      
      
      
      


      I applied this against my test setup and the profiler now shows that the hotspot that was identified earlier, no longer exists. I have attached a couple of screenshots to EJBTHREE-1800 to show the "before" and "after" from the profiler.

      Any thoughts about this?







        • 1. Re: Improving the process of applying AnnotationPlugins on M
          Ales Justin Master

           

          "jaikiran" wrote:

          Any thoughts about this?

          Although this optimizes things, it's wrong.
          There is a reason why we go over MDR. ;-)

          The reason is that annotations can be added to class, ctor, method or field
          via XML or programmatically (with MDR api).

          Perhaps we can add some annotation you can put on the class
          which list possible annotation classes, hence only checking those annotation plugins.

          e.g.
          @MCAnnotations(Inject.class, EJB.class, Resource.class, PersistenceContex.class) // this will be added via MDR / metadata
          public class MyEJB implements IMyEJB
          


          And we would have a check in CommonAnnotationAdapter for this annotation,
          only applying those annotation plugins that match found annotation classes.
          If no such annotation exists, run them all as we do now.

          • 2. Re: Improving the process of applying AnnotationPlugins on M
            jaikiran pai Master

             

            "alesj" wrote:

            Although this optimizes things, it's wrong.
            There is a reason why we go over MDR. ;-)

            The reason is that annotations can be added to class, ctor, method or field
            via XML or programmatically (with MDR api).

            I see. I had no clue what the getComponentMetaData stuff was doing :-)


            The real reason why this AnnotationPlugin processing appears as a hotspot is because the logic looks for annotations on each and every method and fields of the class hierarchy (ex: it reaches upto Object.notify()). My initial intention of attempting a patch was to reduce the number of methods for which the ComponentMetaData is created. i.e. pick only those methods which have annotations, in particular - those annotations which are relevant to plugins.


            "alesj" wrote:

            Perhaps we can add some annotation you can put on the class
            which list possible annotation classes, hence only checking those annotation plugins.

            e.g.
            @MCAnnotations(Inject.class, EJB.class, Resource.class, PersistenceContex.class) // this will be added via MDR / metadata
            public class MyEJB implements IMyEJB
            


            And we would have a check in CommonAnnotationAdapter for this annotation,
            only applying those annotation plugins that match found annotation classes.
            If no such annotation exists, run them all as we do now.

            That might partially improve this performance, because even if the MC bean was applied that annotation (at class level), the logic would still scan a lot of methods/fields (which most of the times don't have any MC annotations to be processed).



            • 3. Re: Improving the process of applying AnnotationPlugins on M
              Ales Justin Master

              OK, let's try with my approach + I'll remove Object method scanning.

              I'll let you know when I'm done,
              and you can then try out the MC/Kernel trunk.

              But like I said, you'll have to apply @MCAnnotations
              to your EJB MC bean creation, adding those possible annotation classes.

              • 4. Re: Improving the process of applying AnnotationPlugins on M
                jaikiran pai Master

                 

                "alesj" wrote:
                OK, let's try with my approach + I'll remove Object method scanning.

                I'll let you know when I'm done,
                and you can then try out the MC/Kernel trunk.

                Wait :-) I'm still not sure that will fix this entirely. I was pointed to the AnnotationEnvironment - let me see how that works and fits in.

                @MCAnnotations(Inject.class, EJB.class, Resource.class, PersistenceContex.class) // this will be add
                ed via MDR / metadata
                public class MyEJB implements IMyEJB


                Just to clarify, we don't actually install the EJB impl classes - instead we deploy internal EJB3 containers. But anyway, i get what you meant :)





                • 5. Re: Improving the process of applying AnnotationPlugins on M
                  Ales Justin Master

                  I've committed initial code (currently no tests).

                  You can check the new CommonAnnotationAdapter
                  and apply the new feature accordingly.

                  • 6. Re: Improving the process of applying AnnotationPlugins on M
                    jaikiran pai Master

                    Ales,

                    I haven't yet given this a try, will do it some time tonight. But as i mentioned earlier, i think this won't solve our issue completely :) Here's what i mean:

                    - As can be seen in the attached MCAnnotationPlugin_BEFORE screenshot, in the JIRA, its the call to MetaDataRetrievalToMetaDataBridge.getComponentMetaData that would have to be minimized
                    - Right now, its being called for every single method/field in the object hierarchy.
                    - Consider this case:

                    public class FirstPOJO
                    {
                    
                     private Integer fieldOne;
                    
                     private Integer fieldTwo;
                    
                     ... totally 20 such fields, which are of no meaning to MC
                    
                     // One single field which is relevant to MC (annotation plugin)
                     @Inject
                     private SomeMCBean tobeInjected;
                    
                     ... 20 getter/setter
                    }
                    
                    



                    public class SecondPOJO extends FirstPOJO
                    {
                    
                     private Integer doNotBotherMC;
                     .. such 20 more fields and getter/setters
                    
                     // the only method, which is relevant to MC (annotation plugin)
                     @Inject
                     public void setSomeBean(SimplePOJO mcbean)
                     {
                     ....
                     }
                    
                    
                    }
                    
                    


                    In this example, we just have a one level hierarchy of the MC pojos. In this hiearchy, there just 1 field and 1 method which MC (ideally) needs to process for annotation plugins. The rest 40 odd methods and fields in this hierarchy are of no relevance to the MC.

                    However, the way it currently behaves, MC first creates the ComponentMetaData for each of these 40 odd fields and methods, then checks for any relevant MC annotations and if not found (correctly) ignores those members.

                    Now, assuming that we introduced the @MCAnnotations annotation. In that case, the POJOs will have this:

                    @MCAnnotations (Inject.class)
                    public class FirstPOJO
                    {
                     ...// rest code remains the same
                    



                    @MCAnnotations (Inject.class)
                    public class SecondPOJO extends FirstPOJO
                    {
                     ...// rest code remains the same
                    
                    

                    This still won't solve our original issue, because on finding the @MCAnnotations (Inject.class), MC is still going to create the ComponentMetaData for all those 40 fields/method (out of which only a couple are relevant for MC).

                    I guess, we either have to reduce the number of calls to getComponentMetaData() or tune the getComponentMetaData() itself.


                    • 7. Re: Improving the process of applying AnnotationPlugins on M
                      Ales Justin Master

                      I'll give it more thought, but any suggestion is welcome. ;-)
                      But it needs to include MDR usage, why, as mentioned before.

                      • 8. Re: Improving the process of applying AnnotationPlugins on M
                        Jason Greene Master

                        Guys we need to stop designing crap that is so over-abstracted, that it becomes *impossible* to optimize.

                        • 9. Re: Improving the process of applying AnnotationPlugins on M
                          Jason Greene Master

                          Now for an actual productive comment :) Is there any reason why the MDR has to eager allocate everything about every element of of every scanned class in memory like that? Any reason it can't just represent metadata as a series of overrides + lazily discovered / proxied calls to reflection data.

                          • 10. Re: Improving the process of applying AnnotationPlugins on M
                            Jason Greene Master

                             

                            "jason.greene@jboss.com" wrote:
                            Now for an actual productive comment :) Is there any reason why the MDR has to eager allocate everything about every element of of every scanned class in memory like that? Any reason it can't just represent metadata as a series of overrides + lazily discovered / proxied calls to reflection data.


                            Ah looking at the code, it seems this is basically what the MDR does, the problem seems to be that the API was designed for fetching specific elements, and depending on the usage, each access could be expensive (especially the reflection loader).

                            So why does it need to scan everything, if the MDR already knows how to fetch it lazily?

                            • 11. Re: Improving the process of applying AnnotationPlugins on M
                              Ales Justin Master

                               

                              "jason.greene@jboss.com" wrote:

                              So why does it need to scan everything, if the MDR already knows how to fetch it lazily?

                              Fetch it how or what?

                              For each instance and its component (= member) the metadata can be different.
                              So, you need to explicitly ask for every component's metadata via its signature.

                              And afaik that's the only way you can get per instance metadata,
                              but you can prove me wrong. ;-)

                              WRT to over-abstracted crap ;-)
                              having a way to add annotations via xml is a nice feature (OK, Emmanuel would disagree :-)),
                              and @JMX is a perfect example of that.

                              Hence when we make an annotation lookup,
                              it should be done properly, taking those per instance annotations into an account.


                              • 12. Re: Improving the process of applying AnnotationPlugins on M
                                jaikiran pai Master

                                Ales,
                                I am not completely familiar with the MC internals, but i guess there might be some place where MC already does annotation scanning (for some other requirement maybe) on the MC bean. Maybe MC could at that point itself "register" appropriate annotation plugins on finding the annotation? Is this possible or is CommonAnnotationAdapter the place where this annotation scanning happens for the first time (the only time?).

                                • 13. Re: Improving the process of applying AnnotationPlugins on M
                                  Ales Justin Master

                                  Afaik this is the only place.
                                  But otoh I don't know what AOP or anyone else is doing.
                                  Although I doubt they do a complete MDR/instance lookup.

                                  • 14. Re: Improving the process of applying AnnotationPlugins on M
                                    Kabir Khan Master

                                    AOP in AS uses the MDR, but only MC beans will have per-instance annotations. Normal woven classes will not

                                    1 2 Previous Next