Re: [aspectj-users] Implementing abstract pointcut that includesnojoinpo

[Ken Pelletier <ken@xxxxxxxx>]

Ron,

I just read your Glassbox article and it's uncanny how perfectly it  
meets my needs.  I was just beginning to look at providing some  
coarse-grained monitoring for an existing application using AspectJ  
and JMX!

The application is a webapp that uses Struts, Spring, Hibernate,  
Axis, and AspectJ.  It seems you'll be touching all of those areas  
with Glassbox.

I'll be keenly watching, and if there's anything I can contribute I  
certainly will.

When's the next installment of the AOP@Work series due to be  
published?   ;-)

- Ken


On Oct 21, 2005, at 11:17 AM, Ron Bodkin wrote:

> I found the ability to specify empty pointcuts that some concrete  
> aspects
> can override helpful in the glassbox inspector project. I use  
> pointcuts to
> indicate common idioms for MVC frameworks (like class controllers  
> and method
> signature or method name controllers), so implementations (monitors  
> for
> Spring, Struts, Axis) can just extend pointcuts for the cases that  
> apply to
> them. This really helped keep modular code when using the worker  
> object
> pattern, and it is nice to not have to explicitly indicate the  
> cases that do
> not apply. I will be discussing this more in part two of my article  
> at the
> AOP@Work article series at IBM Developerworks (stay tuned!)
>
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ken Pelletier
> Sent: Friday, October 21, 2005 6:05 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Implementing abstract pointcut that
> includesnojoinpoints
>
> Thanks for all the quick replies.
>
> Oddly, I did try the pointcut with not spec:
>
> protected pointcut overriddenAbstractPointcut();
>
> But because I'd missed on the parameter matching (the abstract decl
> captures the target for around advice which I'd left off in the sub),
> I mistakenly thought that the syntax was generally incorrect.
>
> So, it's actually the first thing that came to mind, which is always
> a good feeling.
>
> It's also good to see that this can be done in the base aspect; sort
> of a parallel with the template method pattern, only for pointcuts
> and advice.  Good stuff.
>
> Thanks,
>
> - Ken
>
> On Oct 21, 2005, at 12:24 AM, Ron Bodkin wrote:
>
>
> > Ken,
> >
> > This syntax will do it, although it is a little counterintuitive
> > when you
> > first encounter it:
> >
> > protected pointcut overriddenAbstractPointcut();
> >
> > You can also define a default empty value in a concrete pointcut
> > (like this)
> > in an abstract aspect and then override it with a non-empty
> > definition in
> > some concrete aspects. E.g.,
> >
> > abstract aspect Base {
> >    protected pointcut optionalPoint(); // empty
> > }
> >
> > aspect Derived1 extends Base {
> >    protected pointcut optionalPoint() : within(foo..*); // defines
> > for this
> > }
> >
> > aspect Derived2 extends Base {
> >    // optional is empty for this concrete aspect
> > }
> >
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ken Pelletier
> > Sent: Thursday, October 20, 2005 10:06 PM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: [aspectj-users] Implementing abstract pointcut that includes
> > nojoinpoints
> >
> > I have an abstract aspect that declares a couple of abstract
> > pointcuts to be overridden in concrete subclasses.
> >
> > In a particular subclass, however I want to nullify one of those
> > pointcuts; include no joinpoints at all.
> >
> > Is there a common idiom for implementing a concrete pointcut that
> > explicitly includes no joinpoints?
> >
> > I know I can nullify with && if(false), but it smells funny to
> > declare any advice type at all if really none applies.
> >
> > Eg:
> >
> > protected overriddenAbstractPointcut() :
> > <what_would_advice_spec_be_here> && if(false;
> >
> > Regards,
> >
> > - Ken
> >
> > PS: it's probably a design smell in the first place to have abstract
> > pointcuts that sometimes have no applicable concrete implementation,
> > but that's another matter.  :-)
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users