[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] pointcut on termination of java program
|
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