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?
