This post originated from an RSS feed registered with Java Buzz
by dion.
Original Post: EJB3 and AOP: Issues, and an implementation
Feed Title: techno.blog(Dion)
Feed URL: http://feeds.feedburner.com/dion
Feed Description: blogging about life the universe and everything tech
He delves into issues with the EJB 3 specification of interceptors (wrt AOP), for example, having to specify interception via:
@javax.ejb.Interceptor("test.ejb3.MyInterceptor")
He also complains a little about current preview implementations:
After having a look at JBoss EJB 3 and OracleAS EJB 3 previews, I was even more disapointed. Both of them are using a reflective based approach to invoke the interceptors. This means that the performance of the interceptor will be bad, and that a Heisenberg effect will be inevitable and actually fairly big (no wonder that ones will use interceptor to gather performance metrics and thus as soon as you observe the bean, you are observing a different things than what actually happens).
Ones may say this is a microscopic view. It is. But when thinking about EJB 2 stories in the past a sound idea would be to make sure we don't waste resources where we can avoid it. And thinking about JBoss history around AOP, that's rather suprising that the EJB 3 interceptors are not cleanly integrated in their AOP framework. I personnaly consider that we have enough technology around to make it far better, and far more consistent with AOP. Given the impact that AOP will continue to have, ones would better figuring out how to do that now with EJB 3 - assuming that EJB 3 succeeds.
He then spent 1 hour IMPLEMENTING the spec itself using the AspectWerkz AOP container, which is pretty damn impressive IMO.
Alex is even kind enough to put in some thoughts on the spec:
There are some odd things in the 3.5 section of the JSR-220 that I have spot:
(sect. 3.5.1) an interceptor class or EJB can only have one single @AroundInvoke method (advice) in it, and its signature is (sect. 3.5.4) "@AroundInvoke Object someNameOfYourChoice(InvocationContext ctx) throws Exception". Why limitating that to having one single method in the interceptor class or EJB (sect. 3.5.1). My guess is that it is tied to the fact that precedence between advice would then be harder to define in the spec without new semantics. Then one might wonder why an interceptor is not defined as an interface with one single method "intercept(...)" that the EJB could implement as well. Having this interface would suppress the need for @AroundInvoke which sounds like an annotation overuse (unless it is a door open for vendor extension as I will do below..). I'll be interested in EG feedback on that topic, especially in regards of the first limitation.
interceptor components life cycle is unspecified but stateless. That sounds like a very important and powerfull concept of AOP (especially AspectJ) that has been left aside. It is probably an interesting door to provide vendor specific extension ie thread safe interceptor, per bean class interceptor, per bean instance interceptor, per application interceptor etc (but then interceptor component may not be stateless anymore.)
(3.5) an interceptor intercepts all business method (or MessageListener methods for MDB). This means that every interceptor will be poluted with a code snip like "if (invocationContext.getMethod().getName().equals("doSomething")) ..." ie ones will have to write sort of a pointcut in a very loosy way while AOP allow us to write that in a neat way (and further, a way that tools can easy understand to spot which method is intercepted by what).
javax.ejb.InvocationContext is tied to EJB. What will happen when interceptors will end up somewhere else ?
Fortunately, the implementation exposed in this article addresses those issues nicely from a vendor specific extension perspective.
Previous Topic
