1 2 3 Previous Next 37 Replies Latest reply on Aug 18, 2008 9:31 AM by alesj

    Integrating aop-mc-int bean metadata with AS5

    kabirkhan

      I am trying to rewrite the aspect deployers to use the beanmetadata I created in the aop-mc-int project.

      I have created a SchemaResolverDeployer that parses an AOPDeployment from an -aop.xml file. I need to create something that translates the aop annotations to the same.

      Since AOPDeployment is a subclass of AbstractKernelDeployment it gets deployed by the BeanMetaDataDeployer, and this seems to work fine for the very basic example I am playing with.

      So far so good, but in the case of scoped aop, we need to obtain the correct manager to use, and to update that in the entries of all the metadata. What is the best way to do that? I need a PostClassLoader deployer, but it seems hacky to make that look for all the beans that have any of the aop-mc stuff as their classes and then to reset the manager-bean properties on those? Also, we can deploy aop stuff as part of other deployments as well, e.g. -beans.xml, which will result in an AbstractKernelDeployment being attached to the deployment, but do we really want to inspect those as well? There might also be other deployments that use aop type stuff?

        • 1. Re: Integrating aop-mc-int bean metadata with AS5
          kabirkhan

          Also to be picked up by the new deployers, the -aop.xml files will need to be updated to include the namespace:

          <aop xmlns="urn:jboss:aop-beans:1.0">
          


          Should this be a hard requirement for AS5? I could keep the old AspectDeployer as well I guess, but it will be a PITA to maintain the two...



          • 2. Re: Integrating aop-mc-int bean metadata with AS5
            kabirkhan

            My last comment is probably a bit confused. The SchemaResolverDeployer needs namespaces to be set otherwise it falls over, so I think having the namespace should be a hard requirement

            • 3. Re: Integrating aop-mc-int bean metadata with AS5
              kabirkhan

              I had the old AspectDeployer running, which explains why I was getting good results :-(

              Disabling the old POST_CLASSLOADER AspectDeployer, I get no interception. This seems to be because the AnnotationMetaDataDeployer running in the POST_CLASSLOADER stage loads all the classes before the aop metadata beans are deployed by the BeanMetaDataDeployer in the REAL stage.

              I will try disabling AnnotationMetaDataDeployer for the purposes of my tests. I assume the plan is for this to be upgraded to use Ales's javassist annotation parser?

              • 4. Re: Integrating aop-mc-int bean metadata with AS5
                kabirkhan

                Disabling the AnnotationMetaDataDeployer, I am able to run some basic tests

                • 5. Re: Integrating aop-mc-int bean metadata with AS5
                  kabirkhan

                   

                  "kabir.khan@jboss.com" wrote:
                  Disabling the AnnotationMetaDataDeployer, I am able to run some basic tests

                  In other words, interception happens

                  • 6. Re: Integrating aop-mc-int bean metadata with AS5
                    kabirkhan

                     

                    "kabir.khan@jboss.com" wrote:
                    Disabling the AnnotationMetaDataDeployer, I am able to run some basic tests


                    I have created http://jira.jboss.com/jira/browse/JBAS-5558 assigned to Scott for now

                    • 7. Re: Integrating aop-mc-int bean metadata with AS5
                      kabirkhan

                      Another problem when attempting to run the scoped aop tests is that both deployments try to install an interceptor with the same name.

                      Caused by: java.lang.IllegalStateException: Factory$org.jboss.test.aop.scoped.ScopedInterceptor is already installed.
                       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:577)
                       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:443)
                       at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:88)
                      


                      Once I have got the domains set up this should be fine at the aop level, but I need to resolve this somehow on the MC level. The following "nice" xml

                      <aop xmlns="urn:jboss:aop-beans:1.0">
                       <interceptor class="org.jboss.test.aop.scoped.ScopedInterceptor" scope="PER_INSTANCE"/>
                       <bind pointcut="all(org.jboss.test.aop.scoped.POJO)">
                       <interceptor-ref name="org.jboss.test.aop.scoped.ScopedInterceptor"/>
                       </bind>
                      


                      will resolve to something along the lines of

                       <!-- The following 2 are the interceptor definition -->
                       <beanfactory name="Factory$org.jboss.test.aop.scoped.ScopedInterceptor" class="org.jboss.test.aop.scoped.ScopedInterceptor"/>
                      
                       <!-- BY DEFAULT THE INTERCEPTOR TAKES THE NAME OF THE CLASS-->
                       <bean name="org.jboss.test.aop.scoped.ScopedInterceptor" class="org.jboss.aop.microcontainer.beans.Aspect">
                       <property name="advice"><inject bean="Factory$org.jboss.test.aop.scoped.ScopedInterceptor"/></property>
                       <property name="manager"><inject bean="AspectManager" property="manager"/></property>
                       </bean>
                      
                       <!-- The following 2 are the binding and interceptor-ref entries -->
                       <bean name="TestAspectBinding" class="org.jboss.aop.microcontainer.beans.AspectBinding">
                       <property name="pointcut">execution(* org.jboss.test.microcontainer.beans.POJO->*(..))</property>
                       <property name="manager"><inject bean="AspectManager" property="manager"/></property>
                       <property name="advices">
                       <list>
                       <inject bean="TestAspectBinding$1"/>
                       </list>
                       </property>
                       </bean>
                      
                       <bean name="TestAspectBinding$1" class="org.jboss.aop.microcontainer.beans.InterceptorEntry">
                       <property name="manager"><inject bean="AspectManager" property="manager"/></property>
                       <!-- THIS IS THE NAME OF THE INTERCEPTOR -->
                       <property name="aspect"><inject bean="org.jboss.test.aop.scoped.ScopedInterceptor"/></property>
                       <property name="binding"><inject bean="TestAspectBinding" state="Instantiated"/></property>
                       </bean>
                      


                      I could give each deployment it's own prefix or something for the names used, but that will cause problems if the interceptor is declared in one -aop.xml and used in another. One option might be to maintain my own registry in the AOP BeanMetaDataFactory layer, but I don't see how this will work for scoped deployments, since the BMDF is ignorant of scoping at parsing time?




                      • 8. Re: Integrating aop-mc-int bean metadata with AS5
                        kabirkhan

                        Another option might be to use scoped kernels, but I don't think they are being used yet?

                        • 9. Re: Integrating aop-mc-int bean metadata with AS5
                          starksm64

                           

                          "kabir.khan@jboss.com" wrote:
                          I had the old AspectDeployer running, which explains why I was getting good results :-(

                          Disabling the old POST_CLASSLOADER AspectDeployer, I get no interception. This seems to be because the AnnotationMetaDataDeployer running in the POST_CLASSLOADER stage loads all the classes before the aop metadata beans are deployed by the BeanMetaDataDeployer in the REAL stage.

                          I will try disabling AnnotationMetaDataDeployer for the purposes of my tests. I assume the plan is for this to be upgraded to use Ales's javassist annotation parser?

                          I have moved it to PRE_REAL. Were not converting to the generalized deployer Ales is working on in the near term.


                          • 10. Re: Integrating aop-mc-int bean metadata with AS5
                            alesj

                             

                            "scott.stark@jboss.org" wrote:
                            Were not converting to the generalized deployer Ales is working on in the near term.

                            I'm done with my generalized annotation deployer work.
                            OK, I could always use a few more tests, but so far I'm pretty pleased with how things behave.
                            I can have a look how much work it would be to convert AMDD to use my stuff.

                            • 11. Re: Integrating aop-mc-int bean metadata with AS5
                              kabirkhan

                               

                              "scott.stark@jboss.org" wrote:

                              I have moved it to PRE_REAL. Were not converting to the generalized deployer Ales is working on in the near term.

                              Moving it to PRE_REAL does not help aop. Basically, what is happening (and to summarize and hopefully get some feedback on my approach) is:

                              *PARSE stage
                              ** SchemaResolverDeployer parses the aop bean metadata from -aop.xml
                              ** A yet to be created deployer parses the aop bean metadata from annotations using Ales's thingy.
                              A few further points:
                              - If using -aop.xml or aop annotations, an org.jboss.aop.microcontainer.beans.metadata.AOPDeployment is created. This is a subclass of AbstractKernelDeployment.
                              - If using a beans.xml, an AbstractKernelDeployment is created

                              *POST_CLASSLOADER stage
                              ** A new deployer determines the AspectManager to be used based on classloader as before, and the aop bean metadata entries are "massaged" to reference the correct AspectManager. I also hope to be able to resolve the "duplicate interceptor entries in scoped deployments" problem I mentioned earlier in this layer.

                              *PRE_REAL stage
                              ** The AnnotationMetaDataDeployer loads all the classes in the deployment looking for annotations

                              *REAL stage
                              ** The AOPDeployment/AbstractKernelDeployment containing the aop bean metadata is deployed by the BeanMetaDataDeployer, resulting in the aop configuration being deployed to the AspectManager.

                              None of this is committed, it is all work in progress on my machine. But basically we cannot load classes until after the BeanMetaDataDeployer has deployed the aop bean metadata. As before if I get rid of AnnotationMetaDataDeployer I do get some loadtime weaving.

                              I have reopened http://jira.jboss.com/jira/browse/JBAS-5558 and assigned it to AS 5 CR2 since there is no way I will be able to finish this integration task by tomorrow and killing AnnotationMetaDataDeployer is a good enough workaround for me when working on this.

                              • 12. Re: Integrating aop-mc-int bean metadata with AS5
                                starksm64

                                So why can't the aop class weaving/proxy creation be done during a POST_CLASSLOADER stage?

                                • 13. Re: Integrating aop-mc-int bean metadata with AS5
                                  kabirkhan

                                  Because the beans that push the things into the aspectmanager are not deployed until the BeanMetaDataDeployer picks them up in the REAL stage.

                                  Are you suggesting that as part of my POST_CLASSLOADER deployer rip out the aop beanmetadatafactories from the deployment, and deploy them myself there? That could work, they are easily identifiable, but I didn't want to mess around with the deployment too much.

                                  • 14. Re: Integrating aop-mc-int bean metadata with AS5
                                    starksm64

                                    Yes, otherwise no deployers cannot load classes until after the aop deployer beans runs in the REAL phase. That makes the POST_CLASSLOADER and PRE_REAL phases of limited value.

                                    The aop deployer also needs a unique output or we need to use a relative ordering to ensure its the first POST_CLASSLOADER by default.

                                    1 2 3 Previous Next