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" <[EMAIL PROTECTED]> > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin > Sent: Thursday, August 17, 2006 2:13 PM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, Savita > Sent: Thursday, August 17, 2006 2:06 PM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin > Sent: Wednesday, August 16, 2006 12:08 PM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, Savita > Sent: Wednesday, August 16, 2006 11:58 AM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin > Sent: Wednesday, August 16, 2006 11:29 AM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, Savita > Sent: Tuesday, August 15, 2006 3:16 PM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin > Sent: Tuesday, August 15, 2006 1:42 PM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, Savita > Sent: Tuesday, August 15, 2006 12:41 PM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, Savita > Sent: Tuesday, August 15, 2006 12:26 PM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin > Sent: Tuesday, August 15, 2006 11:35 AM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, Savita > Sent: Tuesday, August 15, 2006 11:31 AM > To: [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bodden > Sent: Tuesday, August 15, 2006 6:31 AM > To: [email protected] > 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: [EMAIL PROTECTED] [mailto:aspectj-users- > > [EMAIL PROTECTED] On Behalf Of Conway. Fintan (IT Solutions) > > Sent: Tuesday, August 15, 2006 5:56 AM > > To: [EMAIL PROTECTED]; [email protected] > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Wes > > Sent: 15 August 2006 09:58 > > To: [email protected] > > 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)" <[EMAIL PROTECTED]> > > To: [email protected] > > 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 > > [email protected] > > 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 > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
