[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] pointcut on termination of java program
|
Contributions, whether pattern or anti-pattern, are always welcome!
Data helps both in drawing conclusions and forming hypotheses, and
the AOP solution, as the substitute, does need to be justified.
i.e., Macneil: what constitutes a spaghetti aspect? What did it do,
and what are you replacing it with? Is the problem modularity, or
some other/related 'ility - understandability, maintainability,
testability...
One benefit of following conventions like shutdown hooks and
servlet filters is that your code can be managed like all the
other such code, unbeknownst to you, and uses mechanisms tested in
the field by hoards of applications over the years. When you use
AOP solutions over API/ framework solutions, you take responsibility
for the integration.
Wes
Ron Bodkin wrote:
Hi Macneil,
I partially agree. In this case, using the shutdown hook is better than writing an aspect to do the exact same thing (especially given that I don't advising weaving into VM's because they aren't able to isolate others from the weaaving changes).
However, I don't agree that using non-AOP facilities is always better than using AOP. Non-AOP hooks, interceptors, etc. are generally less powerful and flexible. Consider two cases:
1) Composition. You want to do something when the VM is shutdown or a program is closed: a single pointcut that captures both cases would be cleaner to me (if there were VM support for AOP). Likewise for applying a library aspect a pointcut on shutdown.
2) Servlet filters. They make it much harder to write real filters (that modify the output stream) than aspects, because aspects can hook request processing in flight and manage internal state. Also, servlet filters offer less flexibility in defining where they apply than pointcuts do.
I am not surprised to hear you're seeing overuse of aspect inheritance; in many cases probably overgeneralizing. When you do need multiple aspects, I agree that composition can be better in some cases (e.g., referring to pointcuts from one aspect in another). I also think sometimes you can write reusable aspects that define common operations based on a marker interface. Today this idiom tends to require aspect inheritance too when you'd like to define exclusions (e.g., require these classes to only throw this type of exception, except for these methods). With JSR-175 metadata and a declare attribute definition, the idiom will be even more robust: the exclusions can be expressed with declare attribute and you won't need to override an abstract aspect.
Ron
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
------------Original Message------------
From: Macneil Shonle <mshonle@xxxxxxxxxxx>
To: <aspectj-users@xxxxxxxxxxx>
Date: Mon, Dec-15-2003 3:45 AM
Subject: Re: [aspectj-users] pointcut on termination of java program
Wes Isberg wrote:
You can register to be called on VM shutdown:
Runtime.getRuntime().addShutdownHook(..)
Thanks, I didn't know that. It does perfectly what I want it to do ;)
Jan Van Besien
This sounds like the beginning of some anti-aspect patterns. By which I
mean solutions that could be done in an aspect-oriented manner that are
better done in OO or even procedural styles. In general I think when an
AOP and non-AOP solution can solve the same problem then the non-AOP
solutions should be used.
I'm thinking that examples where aspects can but shouldn't be used could
also be a useful tool for teaching aspects. It would be further
instruction of the semantics, but also a better style guide. And already
I'm maintaining an AspectJ program that has some spaghetti aspects that
I've been removing. (Another anti-pattern I've seen in the overuse of
abstract aspects, much like the overuse of inheritence when composition
would be better in an OO program.)
What do you guys think?
-Macneil
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
