Java Reference
In-Depth Information
Now that you have a handle on traditional interceptors, let's examine CDI's decorators. Un-
like interceptors, decorators are tied to a specific interface.
12.4.2. Decorators
A decorator is very similar to an interceptor. With a decorator you're once again intercept-
ing method invocations on a bean. But unlike an interceptor, you're overriding the methods
you want to intercept. A decorator extends or implements the interface of the bean it's inter-
cepting. As a result, a decorator is tightly coupled to the bean and can implement business
logic. Because you're overriding methods, you have easy access to method parameters.
To better understand decorators, let's focus on the bidding in ActionBazaar. One of the ma-
jor concerns with a bidding site is fraud. When you're bidding against another user, you
don't want to be bidding against the seller who has created a fake account to drive up the
price of the item. To protect against this, you need rudimentary fraud detection. Although
fraud detection is a part of the bidding process, it isn't core to the logic handling the bid.
It's a crosscutting concern similar to logging but more specific. Consequently, you'll im-
plement it using a decorator, as shown in the next listing.
Listing 12.13. Decorator that implements BidManager and intercepts methods
This listing has the code for the decorator. Creating a decorator involves annotating the
class with the @Decorator annotation and implementing or extending the class you
wish to decorate . Then you inject the class you're decorating and mark it as the del-
egate instance . You use a qualifier to ensure you get the correct instance . Finally,
you override the method you're interested in intercepting . Because you're interested
only in intercepting the placeBid method, you mark the class as being abstract.
Search WWH ::




Custom Search