To apply an aspect, you define when to execute the aspect code. Those points in execution are called pointcuts
. An analogy to a pointcut is a regular expression. Where a regular expression matches strings, a pointcut expression matches events or points
within your application. For example, a valid pointcut definition would be, "for all calls to the JDBC method
, call the aspect that verifies SQL syntax."
An entry point could be a field access, or a method or constructor call. An event could be an exception being thrown. Some AOP implementations use languages akin to queries to specify pointcuts. Others use tags. JBoss AOP uses both.
The following listing demonstrates defining a pointcut for the Metrics example in JBoss AOP:
<interceptor name="SimpleInterceptor" class="com.mc.Metrics"/>
<bind pointcut="execution (public void com.mc.BankAccountDAO->withdraw(double amount))" >
<interceptor-ref name="SimpleInterceptor" />
<bind pointcut="execution (* com.mc.billing.->(..))">
<interceptor-ref name="com.mc.Metrics" />
Defines the mapping of the interceptor name to the
Lines 2-4 define a pointcut that applies the
metrics aspect to the specific method
Lines 5-7 define a general pointcut that applies the
metrics aspect to all methods in all classes in the
com.mc.billing package. There is also an optional annotation mapping if you prefer to avoid XML.
For more information, see the JBoss AOP reference documentation.
JBoss AOP has a rich set of pointcut expressions that you can use to define various points or events in your Java application. Once your points are defined, you can apply aspects to them. You can attach your aspects to a specific Java class in your application or you can use more complex compositional pointcuts to specify a wide range of classes within one expression.
With AOP, as this example shows, you can combine all crosscutting behavior into one object and apply it easily and simply, without complicating your code with features unrelated to business logic. Instead, common crosscutting concerns can be maintained and extended in one place.
Note that code within the
BankAccountDAO class does not detect that it is being profiled. Profiling is part of what aspect-oriented programmers deem orthogonal concerns. In the object-oriented programming code snippet at the beginning of this chapter, profiling was part of the application code. AOP allows you to remove that code. A modern promise of middleware is transparency, and AOP clearly delivers.
Orthogonal behavior can also be included after development. In object-oriented code, monitoring and profiling must be added at development time. With AOP, a developer or an administrator can easily add monitoring and metrics as needed without touching the code. This is a very subtle but significant part of AOP, as this separation allows aspects to be layered on top of or below the code that they cut across. A layered design allows features to be added or removed at will. For instance, perhaps you snap on metrics only when you are doing some benchmarks, but remove it for production. With AOP, this can be done without editing, recompiling, or repackaging the code.