RE: [aspectj-users] pointcut on termination of java program

["rbodkin" <rbodkin@xxxxxxxxxxxxxx>]

Hi William,

I agree, AspectJ provides superior language support and I believe better 
modularity. You can write interceptors and pre-plan out a framework, but as 
always you face the architect's dilemna: over-build up front or (and!) 
scramble in the face of unexpected requirements. When you need new context or 
new extension points you face more works. And littering the code with hooks 
is less modular than writing one (or a few) pointcuts to say where the hooks 
should be.

AOP in general and AspectJ in particular not only simplifies writing modular 
support for crosscutting, but it greatly simplifies reading and maintaining 
it and it enables effective tools support.

On Tue, 16 Dec 2003 09:44:01 +0100, Louth, William wrote
> Regarding filter state managment I do not see any less flexibility here.
> Again a developer could easily share state and pass it across executions
> with a current context, which transaction managers have done for a very
> long time. 
Global memory results in high coupling, giving poor modularity. But I was 
really talking about cooperating in processing a single request. As an 
example, I wrote a UI security servlet filter to edit out part of a page: 
coordinating flushing buffers and doing work on the "outside" like this was a 
major pain that rippled through multiple layers. With an aspect, I could hook 
the creation of the output stream in the underlying JSP and it was much 
cleaner. I can also use aspects to proactive filter markup by not executing 
code that generates instead of using a servlet filter to remove it after the 
fact (again an easier programming model).

>... The benefit of AOP in the case of servlet filters is that 
> it allows you to extend an architecture such as J2EE where the contract
> defined via interfaces is not comprehensive for your application needs.
This is another benefit, IMHO.

> I have recently created a tool based on AspectJ (it will be released 
> in 2004) but as the development proceeded more and more of the code was
> extracted from the aspectj (advices..) ...
That's great news. I'm looking forward to hearing more about it. I favor 
writing small aspects that provide adapters and cooperate with classes to do 
the real work. So that's good AOP in my book.

> ... and placed in a standard
> framework thus allowing our system to be used by both AspectJ developers
> and Java developers (standard API). We also have an extension that uses
> Xdoclet to automatically generate the AspectJ classes which merely call
> into the product framework.

This might be a good tradeoff for widespread adoption of your tool and 
framework. I suspect that for those comfortable with AOP using Xdoclet won't 
be helpful. It isn't clear to me if you moved away from advice in favor of 
interception in your framework. If so I suspect it's a trade off selecting 
poorer modularity for easier adoption.

Ron