Interceptor help

[Drew McAuliffe <dr...@lowerunit.com>]

I'm having a bear of a time trying to get a handle on how to create
interceptors. I've worked with the interceptors in xwork/webwork, which I
understand are very different, though I'm assuming some of the core ideas
are the same: you're trying to wrap functionality around a given method
call. I have what I believe is a relatively simple use case, but I just
can't grok the Javassist stuff going on in the sample interceptors.

Here's what I'm trying to do, if anyone can help with a simple example of a
portion of it to set me on my way.
 
I have a service interface, IJournalService, that acts as a DAO-type object
for an interface called IJournal. It has the following simple methods:
public IJournal add(IJournal toAdd, IUserInfo ui);
public IJournal load(Long id, IUserInfo ui);
public IJournal save(IJournal updated, IJournal original, IUserInfo ui);
etc.
 
What I want is to make it easy to add interception to this interface by any
other module that uses the module in which this is defined. There are a
couple of things I want to expose:
1) A base class that will allow an implementation class to implement methods
like 
    public void beforeAdd(IJournal toAdd, IUserInfo ui);
    public void afterAdd(IJournal toAdd, IUserInfo ui);
    public void beforeSave(IJournal updated, IJournal original, IUserInfo
ui);
etc.
This gives me the ability to stick additional functionality into the data
access chain that can't normally be implemented directly in the IJournal
implementation itself. For example, I may need to reevaluate a set of
configured alerts based on a change to the journal item, but can't do that
by detecting changes in the object itself. The "save" method chain is a
logical place for that kind of functionality. The idea is to make it
configurable so that different modules can drop in their own interceptors as
necessary without having to put the functionality in the base object.
 
2) I'd also like to be able to have other modules drop in interceptors for
things like transaction processing or event publishing. It would be ideal to
have those implemented as interceptors so that they would become completely
optional features for a module that was using this module (or, in the case
of transaction processing, the interceptor used would dictate the kind of
transactionality implemented).
 
Any ideas on how to help, or am I looking at the way hivemind does
interception in the wrong way?