Re: [aspectj-users] Why does every Aspect (pertarget(..)) add fieldsand

[Andy Clement <andrew.clement@xxxxxxxxx>]

Can you possibly try something for me? Change the read/write pointcuts from:

  pointcut readLock(): execution(@Lock.Read * * (..));
  pointcut writeLock(): execution(@Lock.Write * * (..));
to
  pointcut readLock(): execution(@Lock.Read * (@Lock *).*(..));
  pointcut writeLock(): execution(@Lock.Write * (@Lock *).*(..));

which means execution of a Read or Write annotated method in a Lock
annotated type.

let me know what happens ?!? did anything change at all ?!?

Andy.

On 09/02/06, Jody Brownell <jody.brownell@xxxxxxxxxx> wrote:
> OK - Here is one of the aspects which I see littering EVERY class in the
> same eclipse project.
>
> >From my understanding the association indicates I only want to crosscut
> on classes which are annotated with @Lock on the type AND @Lock.Read or
> @Lock.Write on one or more methods.
>
>         pertarget(fair(Lock) && (readLock() || writeLock()))
>
> However - As I said - every class is being instrumented with fields and
> interfaces.
>
>
> import java.util.concurrent.locks.ReentrantReadWriteLock;
>
> public abstract aspect LockAspect pertarget(fair(Lock) && (readLock() ||
> writeLock()))
> {
>         declare error: execution(@Lock.Read * * (..)) && !@within(Lock):
>
>                 "@Lock.Read and @Lock.Write cannot be used unless the
> Class/Interface is annotated with @Lock";
>
>         private ReentrantReadWriteLock.ReadLock read;
>         private ReentrantReadWriteLock.WriteLock write;
>         private ReentrantReadWriteLock lock;
>
>         public LockAspect(boolean fair)
>         {
>                 lock = new ReentrantReadWriteLock(fair);
>
>                 read = lock.readLock();
>                 write = lock.writeLock();
>         }
>
>         abstract pointcut fair(Lock lock);
>
>         pointcut readLock(): execution(@Lock.Read * * (..));
>         pointcut writeLock(): execution(@Lock.Write * * (..));
>
>         Object around(): readLock()
>         {
>                 Object o = null;
>
>                 try
>                 {
>                         read.lock();
>                         o = proceed();
>                 }
>                 finally
>                 {
>                         read.unlock();
>                 }
>
>                 return o;
>         }
>
>         Object around(): writeLock()
>         {
>                 Object o = null;
>
>                 try
>                 {
>                         write.lock();
>                         o = proceed();
>                 }
>                 finally
>                 {
>                         write.unlock();
>                 }
>
>                 return o;
>         }
> }
>
> aspect UnfairLockAspect extends LockAspect
> {
>         pointcut fair(Lock lock): @within(lock) && if(lock.isFair() ==
> false);
>
>         public UnfairLockAspect()
>         {
>                 super(false);
>         }
> }
>
> aspect FairLockAspect extends LockAspect
> {
>         pointcut fair(Lock lock): @within(lock) && if(lock.isFair() ==
> true);
>
>         public FairLockAspect()
>         {
>                 super(true);
>         }
> }
>
>
>
>
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
> Sent: Thursday, February 09, 2006 7:18 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Why does every Aspect (pertarget(..)) add
> fieldsand interfaces to classes which are not targeted??
>
> On 08/02/06, Jody Brownell <jody.brownell@xxxxxxxxxx> wrote:
> > Hello.
> >
> > I am writing a series of small POC Aspects which revolve around
> various
> > annotations. I just noticed while debugging that classes not annotated
> with
> > the designated annotations have some extraneous fields/interfaces
> injected
> > during the weaving process.
> >
> > I was hoping someone could explain what it is, why they are there and
> how I
> > can trim the resulting class files during weaving to be as nimble as
> > possible - i.e. remove all the extra fields / interfaces from classes
> which
> > *SHOULD* not be effected by aspects in the first place. Don't get me
> wrong -
> > I understand the need for injecting fields, methods and such to
> support the
> > runtime - but why on classes which have explicitly not been targeted
> with an
> > aspect. Looking at the name (interface
> FairLockAspect$ajcMightHaveAspect )
> > implies this is a forward compatibility feature. Is there a quick way
> to
> > turn this off? I tried the "not reweavable" option in eclipse
> preferences -
> > but that did not help J (I am grabbing at straws)
>
> The interface is there because instances of the object in question may
> have an aspect instance associated with them according to the
> pointcuts and pertarget clause used by your aspects.  Under bug number
> 75442 we did some work to reduce the set of types that are marked
> through some extra analysis of the pointcuts/perclause - that was
> shipped in AspectJ1.5.0M3.  However, there are certain patterns of
> usage (some combination of call and pertarget I think) that make it
> very tough to work out what may or may not have an aspect instance at
> runtime.
>
> You can't turn this off - the best you can do is alter your
> pointcut/perclause definition to limit the effects of it - reducing
> the set of types that might have an aspect instance at runtime.  The
> interface is attached so that code in the aspect that needs to
> determine the aspect instance can rely on certain methods being
> implemented by types and so easily manipulate them.
>
> > Thanks for the Help!!!! Sorry if I am on crack and have missed
> something
> > real obvious J
>
> Can you supply concrete examples of the pointcuts and perclause for a
> typical case where you observe this happening?
>
> Andy.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>