Hi Guys, Thanks for your comments. They have led me down the right path.
I was using to pointcut to exposed elements of the joinpoint that I needed to access in my advice, instead of using the pointcut to specify the joinpoints that I needed. I had already used thisJoinPointStaticPart in the advice and was trying to the arguments with it. I realise now that I should have been using thisJoinPoint in the advice to get the method names and the arguments to the methods. The solution was to change thisJoinPointStaticPart to thisJoinPoint, not pass the arguments as parameter but to use thisJoinPoint.getArgs() instead. This fully covers what I wanted to do. Thanks again, Fintan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin Sent: 21 August 2006 20:30 To: [email protected] Subject: RE: [aspectj-users] Use null for args in pointcut I agree with Wes's question about the contract. To me, it's a little doubtful what you are trying to accomplish with args in your observer. It seems like you are writing special-case logic for thisJoinPoint.getArgs(), to match zero or one argument. What do you expect to do with the first argument, if any? What would you do in a case with more than one argument? Would thisJoinPoint.getArgs() meet your needs? There have been a number of requests for enhancement relating to pointcut bindings. One that seems relevant for this request is https://bugs.eclipse.org/bugs/show_bug.cgi?id=92889, which would allow binding constants (so you could supply a constant value in cases where e.g., null makes sense). In general, I think AspectJ 1.6.0 could benefit from providing more power in unifying (binding and matching) for user pointcuts, e.g., also bug #108895 and bug #106166. HTH, Ron -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wes Sent: Monday, August 21, 2006 10:57 AM To: [email protected] Subject: Re: [aspectj-users] Use null for args in pointcut Hi - If the variable is declared in the pointcut, it must be bound, but you don't have to bind it using args(..), e.g., target(subject) && target(arg) But that sort of begs the question. The abstract pointcut is supposed to define a contract that implementors comply with, and you have no way to comply with it since there is no argument for your join point. If you pretend to comply, it's not clear what's going to happen. Here you might have the source for the abstract aspect and understand the advice on the join points picked out by the abstract pointcuts, but often programmers don't, and they don't know what would be the effect of not complying. hmm. Interesting! Wes ------------Original Message------------ From: "Conway. Fintan (IT Solutions)" <[EMAIL PROTECTED]> To: [email protected] Date: Mon, Aug-21-2006 7:31 AM Subject: [aspectj-users] Use null for args in pointcut Hi *, I have a problem where I have to extend a pointcut in a super aspect. The signature of this pointcut is as follows : protected abstract pointcut subjectChange(Subject s, Object args); One of the aspects which extends this super aspect does not require the 'args' parameter. My overriding pointcut looks like : protected pointcut subjectChange(Subject subj, Object arg) : ( call(* Pot.add(..)) || call(* Pot.refresh()) ) && !within(PotObserverUtilTest) && target(subj) && args(arg); This pointcut matches the Pot.add method, since it does have an argument. However the Pot.refresh() method is not advised since it does not have any arguments. I have to override the abstract pointcut. Is there any way to get the Pot.refresh() advised in this scenario? (args = null?) Any advice gratefully appreciated, Fintan _______________________________________________ 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
