6 Replies Latest reply on Jul 18, 2007 8:32 AM by Manik Surtani

    JBossCache 2.1.0 - AOP framework

    Manik Surtani Master

      The current (1.4.x and 2.0.0) versions of JBoss Cache used hand-wired interceptor chains to apply aspects to the underlying data structure. E.g., a put() call on the cache would:

      1) Use a Method representing an internal equivalent of put(), and pass this along with parameters (wrapped in a MethodCall object) up an interceptor chain.
      2) The interceptor chain would apply an aspect to the call and pass the call up.
      3) The final interceptor would use reflection and invoke the MethodCall on the cache again.

      I think there is good cause to replace this with a more sophisticated AOP framework:

      1) Writing/maintaining our own interceptor handling code is unnecessary and boiler-plate
      2) An AOP fwk would mean that the interceptors can be applied to other objects as well, not just Cache (e.g., Node)
      3) We can do away with the myriad of public "internal" method counterparts to public API methods on the cache - as these are otherwise open to misuse.
      4) Allow for end users to add their own aspects (*)

      (*) This may not be a good thing.

      The criteria I need to think about when picking an AOP framework are:

      1) Efficiency - our use case of the fwk is not a complex one. The fwk should be able to handle this very efficiently.
      2) Bloat - footprint should be small and not bring in (too big) a chain of dependencies.
      3) Readability/maintainability/debuggability - this is part of the reason I want to move away from the current design in the first place.

      I haven't spent a whole lot of time evaluating frameworks yet, and hence this thread to discuss the pros and cons of various frameworks/approaches out there - including the "don't change the current setup" approach.

      Cheers,
      Manik

        • 1. Re: JBossCache 2.1.0 - AOP framework
          Viet Master

          You want also to be sure that JBoss AOP offers a public API that will not change over time.

          • 2. Re: JBossCache 2.1.0 - AOP framework
            Adrian Brock Master

            Of course you should use JBoss AOP. I can think of a number of reaons,
            but probably the most compelling for you (and me but more importantly users :-) are:

            1) If you have problems it is relatively trivial to get a fix/resolution in a "one stop shop"
            at jboss.org

            2) A user doesn't need to understand two sets of configuration to configure JBoss Cache
            with other JBoss AOP usage in the same application (e.g. JBoss AS)

            3) It's possible to use JBoss AOP without any "weaving" (either compile time
            or load time) with the JBoss AOP proxy
            e.g. the JCA prototype does exactly what you are doing (implement a project
            using AOP for the design) but adds the AOP "on the fly" without any special help
            from the classloading.

            4) JBoss AOP works. Its unlikely that your own handwritten framework
            has had the same amount of exposure to testing. It almost certainly contains more
            bugs. :-)

            5) Aspects written for other projects are usuable in your project (and vice versa)

            6) There are some interesting features in the JBoss AOP/MC integration
            that are not available anywhere else. One trivial example is the
            "bind my object into JMX".

            @JMX
            public class CacheImpl {}
            


            Whether it actually does bind it into JMX is dependent not upon you
            writing code to do this, but adding the aspect to the aop config to say
            what the annotation @JMX means.
            No such aspect means there is no binding, and you can choose
            what the implementation of the aspect is according the environment.

            But there are other more interesting examples, such as proper
            dependency management of aspects applied to a bean, e.g.

            @Tx(TxAttribute.REQUIRED)
            public class MyClass {}
            


            But @Tx introduces the transaction demaraction aspect
            which has a dependency on the transaction manager
            @Aspect
            public class TransactionDemarcation
            {
             @Inject
             public void setTransactionManager(TransactionManager tm) {}
            
             public Object invoke(Invocation) throws Throwable {}
            }
            


            Only with JBoss AOP/MC does this transient dependency get recognised
            and properly resolved, i.e. MyClass won't be installed until
            TransactionDemarcation is installed which in turn requires the TransactionManager
            installed.

            • 3. Re: JBossCache 2.1.0 - AOP framework
              Bill Burke Master

              downsides to JBoss AOP:

              * sometimes difficult to diagnose problems as not much work has been put into the pointcut interpreter.

              * Runtime is 1M JBoss AOP + Javassist.

              • 4. Re: JBossCache 2.1.0 - AOP framework
                Manik Surtani Master

                After Kabir's AOP/MC integration presentation yesterday I'm somewhat more convinced of this approach, but a few things still do concern me:

                1) JAR dependency explosion
                2) Memory/performance footprint

                How do other projects deal with the above? Do they just "live with it"? Can 1) be mitigated based on a limited use case such as mine?

                Regarding 2), how does this compare with competing frameworks?



                • 5. Re: JBossCache 2.1.0 - AOP framework
                  Kabir Khan Master

                  Don't you need the AOP jars for POJO Cache anyway? Or are you doing separate downloads for POJO and Plain Cache?


                  4) Allow for end users to add their own aspects (*)

                  (*) This may not be a good thing.

                  I have some vague ideas for a "locked" configuration of aspects for particular joinpoints