When I was first starting on the Tapestry 5 code base, I started using AspectJ for parts of the framework. I wrote some clever aspects for defensive programming (cementing "don't accept null, don't return null" as an iron-clad rule) and created some aspects to simplify concurrent access to certain resources.
I certainly never expected Tapestry developers to have to use AspectJ: it's certainly a powerful tool, but it has downsides: AspectJ affects the build process in a signifcant way, it's tricky to use properly, it adds a huge runtime dependency and the plugin for Eclipse made the IDE slow(-er) and (more) unstable. I eventually stripped out the AspectJ code entirely and restricted the framework to traditional code (plus, of course, Javassist).
In the interrum a number of aspect oriented touches have appeared in Tapestry. Certainly, the entire mixins concept is an approach to aspect orientation. Likewise, service decorators. In fact, much of the class transformation mechanism is a way of performing aspect-oriented operations on Tapestry component classes. Creating your own parameter binding prefixes (something I often do for client projects) is another aspect: one focused on streamlining how data gets into or out of a component.
However, all of these techniques can be cumbersome; they are built on the Javassist "language" which is another tool that can be difficult to use properly. I've created layers around Javassist to make things easier, but it's still an uphill battle.
Earlier in the week I was able to take the Javassist out of service method advice. However, that's not quite enough ... I want it to be easier to apply advice to component methods just as easily.
Well, I did just that. There is a ComponentMethodAdvice that can be applied to component methods. It's only a slight variation from the MethodAdvice used on service interfaces (the difference being that the invocation allows access to the ComponentResources of the component).
Here's a concrete example: Part of tapestry-hibernate is the @CommitAfter annotation, which is used to commit the running transaction after invoking a method. There's a decorator that can be applied to services, and there's a worker that is automatically threaded into the Component Class Transformation chain of command.
The worker used to use the Javassist approach to decorate method invocations with the desired logic: commit the transaction when the method completes normally, or with a checked exception. Abort the transaction when the method throws a runtime exception.
First, the old code:
public class CommitAfterWorker implements ComponentClassTransformWorker
{
private final HibernateSessionManager _manager;
public CommitAfterWorker(HibernateSessionManager manager)
{
_manager = manager;
}
public void transform(ClassTransformation transformation, MutableComponentModel model)
{
for (TransformMethodSignature sig : transformation.findMethodsWithAnnotation(CommitAfter.class))
{
addCommitAbortLogic(sig, transformation);
}
}
private void addCommitAbortLogic(TransformMethodSignature method, ClassTransformation transformation)
{
String managerField = transformation.addInjectedField(HibernateSessionManager.class, "manager", _manager);
// Handle the normal case, a succesful method invocation.
transformation.extendExistingMethod(method, String.format("%s.commit();", managerField));
// Now, abort on any RuntimeException
BodyBuilder builder = new BodyBuilder().begin().addln("%s.abort();", managerField);
builder.addln("throw $e;").end();
transformation.addCatch(method, RuntimeException.class.getName(), builder.toString());
// Now, a commit for each thrown exception
builder.clear();
builder.begin().addln("%s.commit();", managerField).addln("throw $e;").end();
String body = builder.toString();
for (String name : method.getExceptionTypes())
{
transformation.addCatch(method, name, body);
}
}
}
Can you tell where that logic (when to commit and abort) is? Didn't think so, it's obscured by lots of nuts-and-bolt logic for creating the Javassist method body.
All that stuff with the BodyBuilder is a way to assemble the Javascript method body piecewise. It's certainly meta-programming, but it's only a few steps ahead of writing the Java code to a temporary file and compiling it. That's great for people into the meta-coding concept (count me in) but sets the bar so high that most people will never be able to tap into the power.
That's where the advice comes in: the new version of the worker is much simpler:
public class CommitAfterWorker implements ComponentClassTransformWorker
{
private final HibernateSessionManager _manager;
private final ComponentMethodAdvice _advice = new ComponentMethodAdvice()
{
public void advise(ComponentMethodInvocation invocation)
{
try
{
invocation.proceed();
// Success or checked exception:
_manager.commit();
}
catch (RuntimeException ex)
{
_manager.abort();
throw ex;
}
}
};
public CommitAfterWorker(HibernateSessionManager manager)
{
_manager = manager;
}
public void transform(ClassTransformation transformation, MutableComponentModel model)
{
for (TransformMethodSignature sig : transformation.findMethodsWithAnnotation(CommitAfter.class))
{
transformation.advise(sig, _advice);
}
}
}
Really simple! The advice is very clear on what happens when, as long as you realize that proceed() invokes the original method (the method "being advised"), and also Tapestry's way of handling thrown exceptions: runtime exceptions are not caught by proceed(), but checked exceptions are.
This simplicity opens up the power of aspects without all mental overhead of AspectJ's join points and declarative point-cut language. It's only a fraction of AspectJ's power, but it's a very useful fraction.
Further, AspectJ works entirely in a static way (it primarily works at build time), but this style of AOP is a mix of declarative and imperative. In other words, we can have active code decide on a component-by-component and method-by-method basis what methods should be advised. The above example is typical: it's driven by an annotation on the method ... but other cases jump to mind: triggered by naming conventions, by parameter or return types, or by thrown exceptions. And there's no guesswork about going from the advice to Tapestry services: its the same uniform style of injection used throughout Tapestry.
In the future, we may add other options, such as advice for field access, but what's just checked in is already a huge start.
