Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Arg evaluation

Just be aware that the implementation of args(..) can change.  There may be
some movement in the direction of static (compile-time) proofs that can avoid
runtime checks, and other implementations may do less at compile-time.

Note that some (kinded) pointcuts pick out the declared argument type
which can be evaluated at weave-time.  See, e.g., execution(..), 
call(..) and handler(..):

   !execution(* *(int, ..))

Wes

> ------------Original Message------------
> From: "Chandan, Savita" <Savita.Chandan@xxxxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Thu, Aug-17-2006 3:13 PM
> Subject: RE: [aspectj-users] Arg evaluation
>
> Thanks. I remember reading the Hugunin paper, but I guess I 
> concentrated
> more on the performance section of the paper.
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Thursday, August 17, 2006 2:13 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] Arg evaluation
> 
> You could read the paper "Advice Weaving in AspectJ" (see
> http://hugunin.net/papers/aosd-2004-cameraReady.pdf) for a description
> of
> how it is implemented. There is also some related material in Eclipse
> AspectJ (e.g., page 174 and pages 186-192). 
> 
> But if you just want to determine where a runtime test is occurring you
> can
> often use the AJDT plugin to see a gutter annotation. The annotation
> will
> show you whether there's a runtime test or not. You can also vary parts
> of
> the pointcut to see which parts are generating runtime tests...
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
> Sent: Thursday, August 17, 2006 2:06 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: [aspectj-users] Arg evaluation
> 
> Hi Ron,
> 
> I was looking into see how AspectJ does Arg evaluation during compile
> time. Couldn't find any site online that explained this. Do you know of
> any sources that explain this? May be one of the published books.
>  
> Thank you 
> Savita
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Wednesday, August 16, 2006 12:08 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> args is a builtin pointcut designator. See the AspectJ programmer's
> guide
> (e.g.,
> http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcut
> s.ht
> ml) or for more detail a good book on AspectJ such as AspectJ in Action
> or
> Eclipse AspectJ.
> 
> Most of the args tests would be evaluated at compile-time. For 
> arguments
> that are an interface there would be instanceof tests for String and
> Immutable.
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
> Sent: Wednesday, August 16, 2006 11:58 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
>  
> How expensive would this be during run time?
> 
> before(Object mutable) : criticalPoint() && !args(int, ..) &&
> !args(double,
> ..) && ... && !args(String, ..) && !args(Immutable, ..) && 
> args(mutable,
> ..)
> {
> 
> Wow! does AspectJ provides the above constructs args(...) etc or are
> they user defined methods?
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Wednesday, August 16, 2006 11:29 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> Hi Savita,
> 
> Memento is certainly a good option in many cases. I would think about
> how to
> efficiently record what I needed to record by case (e.g., are there
> interfaces or abstract base classes that have a common strategy). In
> some
> cases you might be able to record just a primary key for persistent
> entities
> and then be able to see what state they were in at the time something
> happened (e.g., from audit records).
> 
> The most natural way to identify the mutable arguments with AspectJ is
> with
> reflection. However, you can optimize many common cases (up to N
> arguments)
> with extra work like this:
> 
> //1st argument
> before(Object mutable) : criticalPoint() && !args(int, ..) &&
> !args(double,
> ..) && ... && !args(String, ..) && !args(Immutable, ..) && 
> args(mutable,
> ..)
> {
>    handleMutable(mutable, 0);
> }
> 
> // 2nd argument
> before(Object mutable) : criticalPoint() && !args(*, int, ..) &&
> !args(*,
> double, ..) && ... && !args(*, String, ..) && !args(*, Immutable, ..) 
> &&
> args(*, mutable, ..) {
>    handleMutable(mutable, 1);
> }
> ...
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
> Sent: Tuesday, August 15, 2006 3:16 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> Thanks Ron.
> 
> For the mutable objects I was thinking of two solutions to save the
> snapshot.
> 1. saving the snapshot as String ( very expensive!!!, wouldn't go for
> this) 
> 2. create a memento object as Mathew mentioned in his email with the
> timestamp as a key and query for that memento object ( have to take a
> hit of object creation.. but we can control the depth of state here,
> because flight recorder logging has to be brief) for the particular 
> time
> stamp when required. 
> 
> Also is there a way to get parameters of type Object without iterating
> through each parameter and checking if it of the type Object, because
> this is a big runtime hit? And this is what I was trying to avoid (
> using reflections to parse the arguments during runtime) with my 
> earlier
> solution( apt -> ajc etc etc).
> 
> The approach below looks much simpler, but I need to understand it
> better.
> In the approach below apart from the ID don't we still need to grab the
> snapshot of the object at the time of logging?  
> Also how would this rule out using reflection to parse arguments during
> runtime.
> 
> Thanks again for response.
> Savita
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Tuesday, August 15, 2006 1:42 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> How about having an interface for types that you need to snapshot for
> your
> flight recorder, e.g.,
> 
> interface Identifiable {
>     public Object getIdentityToken();
> }
> 
> aspect Recorder {
>     declare parents: com.foobar.domain..* implements Identifiable;
>     public Object PreserveIdentity.getIdentityToken() {
>         return toString(); // choose a default that makes sense for 
> your
> domain
>     }
>     public Object Entity.getIdentityToken() {
>         return getId(); // overriding for certain cases...
>     }
> }
> 
> Then your flight recorder could use reflection to find objects
> implementing
> Identifiable and store identity tokens for them, but just use the join
> point
> to handle other objects.
> 
> The use of reflection in apt might be a little more efficient, but I
> don't
> see how it gives you an ability to write correct code, and as you note
> you
> have a drawback of a more complex tool chain with code that's harder to
> maintain and debug. Even with apt, what are you going to do to preserve
> the
> identity of mutable arguments?
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
> Sent: Tuesday, August 15, 2006 12:41 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> Oops sent it before completing the response. 
> 
> The solution I was thinking of was to use 'apt' before compilation to
> generate advise code for each annotated method. The parameters for each
> method would be resolved using reflection during the precompilation
> step, where the code gets generated. Next step is to run ajc to weave
> the code. This way I don't have to use reflection during run time, but
> the draw back is I will be generating lot of code. Cant think of any
> other solution.
> 
> Any ideas/ feedback on this is most welcome.
> 
> Iam currently working to see if this is a feasible solution.Iam new to
> both using annotations, apt and AspectJ and Iam exploring how to code
> for all of this. 
> Any useful guides to speed up my learning process are welcome as well.
> 
> Thanks,
> Savita
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
> Sent: Tuesday, August 15, 2006 12:26 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> Thanks for your response.
> In the use case where the objects are going to be logged Iam looking at
> a different strategy.
> 
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Tuesday, August 15, 2006 11:35 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> Savita,
> 
> Yes you can cache a JoinPoint object in memory and use it whenever you
> like.
> In the attached email Matthew suggested you could do this, but he noted
> an
> issue you would face is that the related objects (getArgs, getThis,
> getTarget) can be mutable. So the objects the join point referenced can
> change state after you cache it, which probably wouldn't be want you
> want
> for a flight recorder.
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
> Sent: Tuesday, August 15, 2006 11:31 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
>  Eric,
> 
> Would this also mean that I can cache thisJoinPoint in memory and then
> use it later long after the advise is done?
> Or 
> should this be used within the scope of the advice?
> 
> I have attached the response I received earlier on this.
> 
> Thanks,
> Savita
> 
> 
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Eric Bodden
> Sent: Tuesday, August 15, 2006 6:31 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] thisJoinPointStaticPart
> 
> Note that in such a situation it's no problem to capture the
> "thisJoinPoint" object in the advice and then pass it to the method as
> an argument.
> 
> 
> Eric
> 
> 
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-
> > bounces@xxxxxxxxxxx] On Behalf Of Conway. Fintan (IT Solutions)
> > Sent: Tuesday, August 15, 2006 5:56 AM
> > To: wes@xxxxxxxxxxxxxx; aspectj-users@xxxxxxxxxxx
> > Subject: RE: [aspectj-users] thisJoinPointStaticPart
> > 
> > Doh,
> > 
> > Of course it is!  I was trying to use it in a method called from an
> > advice.
> > 
> > Sometimes it is the simple things that trip us up.
> > 
> > Many thanks,
> > 
> > Fintan
> > 
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Wes
> > Sent: 15 August 2006 09:58
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] thisJoinPointStaticPart
> > 
> > 
> > Hi -
> > 
> > this..JoinPoint.. reflective variables are only valid in the body of
> > advice, as discussed here:
> > 
> > http://www.eclipse.org/aspectj/doc/released/progguide/semantics-
> > advice.h
> > tml#reflective-access-to-the-join-point
> > 
> > thisJoinPoint{StaticPart} refers to the join point being advised, and
> > thisEnclosingJoinPointStaticPart refers to the join point enclosing
> the
> > current one, if known.  They are of type JoinPoint or
> > JoinPoint.StaticPart.
> > 
> > Does that help? - wes
> > 
> > 
> > ------------Original Message------------
> > From: "Conway. Fintan (IT Solutions)" <Fintan.Conway@xxxxxx>
> > To: aspectj-users@xxxxxxxxxxx
> > Date: Tue, Aug-15-2006 1:43 AM
> > Subject: [aspectj-users] thisJoinPointStaticPart Hi *,
> > 
> > I am trying to retrieve the method which is firing an advice.  I am
> > trying to use 'thisJoinPointStaticPart.toString()'.
> > 
> > When I type thisJoinPointStaticPart into Eclipse it shows up in bold
> > and purple - so far so good.  However when I save the aspect file,
> > Eclipse gives me the error - "
> > thisJoinPointStaticPart cannot be resolved" .  I have imported
> > org.aspectj.lang.*; I am using Eclipse 3.2 and AJDT 1.4. Any advice
> > (pun
> > intended) is appreciated, Regards, Fintan PS same problem for
> > thisJoinPoint.
> > 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > 
> > 
> > * ** *** ** * ** *** ** * ** *** ** *
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed.
> > Any views or opinions presented are solely those of the author, and 
> do
> > not necessarily  represent those of ESB.
> > If you have received this email in error please notify the sender.
> > 
> > Although ESB scans e-mail and attachments for viruses, it does not
> > guarantee that either are virus-free and accepts no liability for any
> > damage sustained as a result of viruses.
> > 
> > * ** *** ** * ** *** ** * ** *** ** *
> > 
> > _______________________________________________
> > 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
> _______________________________________________
> 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
> _______________________________________________
> 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
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 



Back to the top