JBossCache 2.1.0 - AOP framework

[manik]

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

[julien1]

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

[adrian.brock]

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.

[bill.burke]

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.

[manik]

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?

[kabirkhan]

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

[manik]

Separate binary distros.