| RE: [aspectj-users] pointcut on termination of java program |
Ron,
Your examples could easily be solved with adaptors and interface (contracts). The adaption to the calling of a block of shared/common code is what AspectJ is doing anyway. AspectJ provides superior language support for this via pointcuts and advices but interceptors and a well designed framework are not necessarily any less powerful. The difference here is that its in the language and not dependant on the talent of the developer to create an efficient interception framework with defined extenion points.
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. 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.
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..) 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.
Regards,
William
-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Ron Bodkin
Sent: Monday, December 15, 2003 5:58 PM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] pointcut on termination of java program
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