This post originated from an RSS feed registered with Java Buzz
by Jason Carreira.
Original Post: Interceptors in EJB 3.0?
Feed Title: Jason Carreira
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Personal Aggrandizement
While I initially responded than it would be interesting to have the specification define interceptors for EJB's formally, I am slowly changing my mind. The more I think about it, the more I believe it would be a bad idea to add this to the EJB specification. There are several reasons to this, which I'll examine in turn:
Lack of use cases
AOP
The point is not AOP, the point is interceptors being applied at a certain well-defined point in a call stack. This is very powerful and very easy, done correctly. Think Servlet Filters, not AOP. Check out XWork, where we've applied this pattern to a command-pattern implementation with great success.
Right now, EJB basically has these interceptors hardcoded in for security, transactionality, etc. Now if these standard services were mapped to given names ("Security" and "Transaction" come to mind) then each vendor could map their own implementations of these interceptors to these names in the Interceptor registry and, instead of the complex deployment descriptors we have now, we could have a single place to apply any set of interceptors in any order. We could also allow (advanced) users to remap these default keys to replace the security interceptor or the transaction interceptor, as well as add in any other interceptor you need.
Allowing this, and putting it in external configuration files, will allow our legacy J2EE apps (which is becoming reality now, as J2EE has been around long enough for many products/projects to have moved from an active development cycle to maintenance) to be easily integrated with other apps as the need arises without having to change the app itself and re-test /re-deploy...
Previous Topic
