1 Reply Latest reply on Apr 27, 2005 4:26 PM by Adrian Brock

    status of AOP/MC integration

    Bill Burke Master

      As far as the requirements goes, with the current code integration I have:

      1) Met class-weaved aspect dependency propagation to the MC. Please see the aspect/src/test/.../kernel tests.

      2) I have implemented a proxy-based solution that will work with classes that HAVE NOT been implemented with AOP that will create a class-proxy with all interceptors,aspects,annotation overides, and mixins

      3) I have implemented a PER BEAN to AOP when you want to add interceptors/aspects/annotation overrides on a per bean basis. Currently I have not tested this yet, but it is only implemented with proxies until I implement the same per-instance API into my bytecode weaver.

      So, I need to:

      * write some basic tests for #3
      * Implement the refactored per-instance API for AOP.

      The thing is, having a design meeting in Boston was nice and all, it got things started, but the idea that you can actually define everything up front without writing one line of code is a bit naive. There's going to be changes in the interfaces as you iterate toward the final production release.

      At first I started going to the path of using ClassInfo's to do all the integration with the Microcontainer and AOP and later decided against this approach. What I found out was:

      1) To use ClassInfo's in AOP would require a very large refactoring of JBoss AOP. I started down this path and actually wrote a lot of code, but figured that it would almost totally refactor JBoss AOP before I was able to run one test. I didn't think I could do this in the fragmented time slots I had to work on this with all the other stuff I am responsible for.

      2) Using Javassist to create ClassInfo's as discussed in the Boston design meeting was just way too slow. Kernel boottime would just be crippled if we did this. The whole purpose of using Javassist to create ClassInfo's was that we needed to know aspect dependencies before the class had done static initialization because of the way JBoss AOP initialized itself. Using Java reflection to create ClassInfo's is JUST FINE. After some research I found that Java reflection only triggers class static initialization when Class.forName() is called, newInstance(), or a field/method invocation. So using Javassist to create ClassInfos is just pure overhead and not needed.

      3) Although I agreed in Boston that per-bean AOP would be done through annotations, i had an issue that MC would be responsible for this. JBoss AOP already has an annotation override facility and there is no reason we cannot reuse this facility. This is why I added a recent changes to ClassAdapter and BeanMetaData (the metadata stuff). The MC is good at creating objects from XML. Might as well take advantage of it rather than creating a bunch of crappy gluecode.

        • 1. Re: status of AOP/MC integration
          Adrian Brock Master

          My prob lem is not so much that you have changed tack to provide
          a more pragmatic implementation, nor that you are iterating a solution.

          My problem is that you are creating interfaces that cannot survive all the requirements
          we have down the road.

          I would prefer a solution that looks like it will meet the requirements (even if it doesn't actually work - it can be fixed) to one where we are going to incompatibly break things
          to do the more complicated stuff in future releases.