11 Replies Latest reply on Apr 19, 2005 12:51 PM by adrian.brock

    Proxy implementation and advisors

      We discussed this in Boston, but I want to make sure you agree with my summary.
      http://jira.jboss.com/jira/browse/JBAOP-82

      Do you plan to support proxies on non-weaved code?

      I had a look at the current proxy implementation, the EJB3 and new JMS
      usage (which all do different but similar things). But all of them require weaving
      of the target object (mainly through the assumption that there is a ClassAdvisor).

      The only mechanism to dispatch to non-weaved code seems to be with
      ProxyMixins, but these don't allow advice/interceptors and also require
      javassist generated classes.

      You can make it work if you want to create your own interceptors and
      do insertInterceptor() by hand, but this does not work if you want to use
      scopes/domains or externalize the configuration.
      I'm pretty certain this isn't the intended usage.

      I got very confused by some of the names of the different advisor classes,
      it is not very clear what the intention of each is supposed to be?
      Of course this is mostly my unfamialirty with the code as a re-newbie ;-)

      My interest in this is for the annotated deployment of a javabean into an MBean.
      Within JBoss it is fine to be able to weave javabean to add the mixin using @MBean
      since we control the classloader, but for the standalone JMX this may not be possible so
      we need to fallback to a nonweaved class with a proxy using the same interceptors.

        • 1. Re: Proxy implementation and advisors
          bill.burke

          Look at the EJB3 code for examples, but it uses something called a ClassContainer. (I know the names are confusing).

          My thinking was a proxy (java.lang.reflect or a javassist one) that creates an invocation and delegates to this ClassContainer.Eventually, the InstanceAdvisor will be replaced by some extension of the ClassContainer and we'll have unified APIs for adding advices/interceptors to a proxy or to an instance.

          As far as your problem goes, if you want to use @MBean with weaving you DO NOT have to have control over classloading. Just use the AOPC compiler. For @Mbean anyways, we should pick one or the other. Either weave or don't weave.

          BTW, why don't you finish GenericBeanFactory instead of looking at this stuff?

          • 2. Re: Proxy implementation and advisors

             

            "bill.burke@jboss.com" wrote:
            Look at the EJB3 code for examples, but it uses something called a ClassContainer. (I know the names are confusing).

            My thinking was a proxy (java.lang.reflect or a javassist one) that creates an invocation and delegates to this ClassContainer.Eventually, the InstanceAdvisor will be replaced by some extension of the ClassContainer and we'll have unified APIs for adding advices/interceptors to a proxy or to an instance.

            As far as your problem goes, if you want to use @MBean with weaving you DO NOT have to have control over classloading. Just use the AOPC compiler. For @Mbean anyways, we should pick one or the other. Either weave or don't weave.


            My thinking was the class adapter would go through something like the following logic:

            Object implements Advised -> InstanceAdvisor
            (!Object implements Advised) && canWeave -> Runtime Weaving
            (!Object implements Advised) && canWeave == false -> ProxyAdvisor

            With this being transparent to the "user", i.e. me JMX.

            My problem with using AOPC is that I cannot predicate a standalone MBeanServer
            on the user using AOPC. They just do:
            MBeanServer server = MBeanServerFactory.createMBeanServer();
            server.registerMBean(objectName, new MyMBean());
            


            In this case, MyMBean.class is not weaved for AOP and it is too late
            to do it in registerMBean because they already loaded the class.

            What I want to do inside registerMBean is use an AOP domain configuration
            to wrap the MBean in advices, but regardless of the advisor implementation.

            This is one of those backward compatibility requirements.

            • 3. Re: Proxy implementation and advisors
              • 4. Re: Proxy implementation and advisors

                 

                "adrian@jboss.org" wrote:

                What I want to do inside registerMBean is use an AOP domain configuration
                to wrap the MBean in advices, but regardless of the advisor implementation.


                Well actually, going forward, this will more annotation driven rather than the
                public class XXX implements XXXMBean
                

                pattern.

                But the class still might not be pre-weaved.

                • 5. Re: Proxy implementation and advisors

                   

                  "bill.burke@jboss.com" wrote:

                  BTW, why don't you finish GenericBeanFactory instead of looking at this stuff?


                  To more completely answer your question, I am at an impass waiting for:
                  AOP integration
                  JBossXB parsing
                  and to a lesser extent classloading.

                  So I've moved up the stack and I'm now looking at how we integrate JMX/MicroContainer
                  which basically involves using the same advice stack to wrap the POJOs regardless of which api is used to register/invoke them.
                  Which has come back to the AOP integration again :-)

                  • 6. Re: Proxy implementation and advisors
                    bill.burke

                     

                    "adrian@jboss.org" wrote:


                    My thinking was the class adapter would go through something like the following logic:

                    Object implements Advised -> InstanceAdvisor
                    (!Object implements Advised) && canWeave -> Runtime Weaving
                    (!Object implements Advised) && canWeave == false -> ProxyAdvisor

                    With this being transparent to the "user", i.e. me JMX.



                    In your example the Class adaptor not only has to do the above, but also is it already woven. We do not want to do all this pre-processing at class load time or this "lightweight" container will take forever to boot up. The slow pre-processing is the same reason I did not want to have javassist create ClassInfo structures.


                    This is one of those backward compatibility requirements.


                    This is far from a backward compatibility requirement considering we don't have an official @MBean implementation.

                    • 7. Re: Proxy implementation and advisors
                      bill.burke

                      The hard part about the GenericBeanFactory is creating all the metadata. Also, how about all the metadata overrides? I think this should be a separate API with the ClassAdapter instead of the way we proposed it in Boston. Not only would this get rid of the need for javassist to preprocess and create ClassInfo's, but it would also not force me to totally refactor (practically rewrite) jboss AOP to use ClassInfo's to bind aspects.

                      • 8. Re: Proxy implementation and advisors

                         


                        In your example the Class adaptor not only has to do the above, but also is it already woven. We do not want to do all this pre-processing at class load time or this "lightweight" container will take forever to boot up. The slow pre-processing is the same reason I did not want to have javassist create ClassInfo structures.


                        I thought you already had an option for whether it does the weaving at runtime?

                         <mbean code="org.jboss.aop.deployment.AspectManagerService"
                         name="jboss.aop:service=AspectManager">
                        <!-- HERE -->
                         <attribute name="EnableTransformer">false</attribute>
                        


                        This is far from a backward compatibility requirement considering we don't have an official @MBean implementation.


                        I'm talking about when it doesn't (that's why I said "going forward")
                        i.e. it follows the old fashioned Standard MBean pattern described above.

                        1) I want to be able to register it in the mbean server (backwards compatibility) but also
                        make it available via injection in the MC.
                        2) Vice-versa, register a javabean written for the MC and add @MBean (not backwards compatible because this obviously didn't exist previously like you say).

                        Whichever method is used, I only want to maintain one implementation of the advices
                        and adding things like role based security should just be done with the standard aop advice.

                        OFF-TOPIC:
                        Even though in practice I cannot even do that because for a while (a few versions hence)
                        because I have to maintain XMBean (along with its inteceptor model)
                        but as just another ModelMBean implementation
                        (this also for backwards compatibility since we have users using it).

                        • 9. Re: Proxy implementation and advisors

                           

                          "bill.burke@jboss.com" wrote:
                          The hard part about the GenericBeanFactory is creating all the metadata. Also, how about all the metadata overrides? I think this should be a separate API with the ClassAdapter instead of the way we proposed it in Boston. Not only would this get rid of the need for javassist to preprocess and create ClassInfo's, but it would also not force me to totally refactor (practically rewrite) jboss AOP to use ClassInfo's to bind aspects.


                          I've got to the stage where I don't care and just want something that works. :-)
                          Even if it is just the simple use cases.

                          Without something concrete to build on and write test cases to show missing features, it
                          is just lots of arguments in the forums and more delays.

                          I've already been through a couple of refactors (both the Bean model and xml)
                          and still don't know what the final api looks like, that's why I call it an impass and started
                          working on other things.

                          • 10. Re: Proxy implementation and advisors

                            Simple usecase tests for AOP/MC integration:
                            http://jira.jboss.com/jira/browse/JBAOP-109
                            Assigned to me....

                            • 11. Re: Proxy implementation and advisors

                              I've started this - commit message:

                              Some kernel/aspect tests for annotations.
                              
                              To run: compile for Java5 then ant -f build-test50.xml run-tests
                              
                              TODO: Fix the dependency aspect so it works, I'm only doing
                              this to simulate field field injection which isn't *yet* in the BeanInfo
                              model.
                              TODO: Didn't realise until too late that there is already is a test50 source
                              directory and associated build (needs consolidating)
                              


                              I'll fix the dependency aspect later today, I've got to look at a bug that is
                              holding up Francisco.