This topic has not yet been written. The content below is from the topic description.
As is shown in this example, around advices can generally be broken into two related before and after advices. The reverse is also true. However, there are some subtleties that can help you to choose one form or the other. First of all, these are features that are available only to around advices: capability of replacing the entire joinpoint execution, by skipping the call to Invocation.invokeNext() method; capability of skipping the invocation of subsequent around advices and interceptors, by calling Invocation.invokeTarget() instead of Invocation.invokeNext(); addition of meta-data, available on Invocation objects only. When you need one of those advanced features, you should use an around advice or interceptor. Besides, there are aspects that cannot be implemented as a pair of before and after advices. An example would be the SynchronizedAspect shown before. A synchronized block cannot be broken into two blocks and achieve the same result as one single synchronized block. In the example, we wrote a similar, more complex aspect to illustrate the before/after advice concept. In real applications, however, this aspect would not be replaced by a more complex one, unless this could bring advantages to the application. On the other hand, before and after advices also provide some advantages. A pair of related before/after advices: is lightweight, when compared to around advices can be bound to different joinpoints. The before advice can be invoked before joinpoint A and the after advice, after joinPoint B Since they are more lighweight, prefer using a pair of before/after advices, unless you have a reason to do otherwise. Regarding the second item in the list, it can be extremely useful in the case of MutexAspect. Instead of controling the multi-threaded access to a single joinpoint, we could obtain the lock before a joinpoint, and release it later, after a different joinpoint execution. This allows the synchronization of a sequence of joinpoints as if they were a single unit. Lets remark that replacing the joinpoint return value is not a feature exclusive to around advices and interceptors. An after advice can also return a value (for more on this, refer to the Return Types example).