[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] Parameters
|
I would be nervous about having the same single join point result in multiple distinct matches for the same pointcut. It breaks a key assumption underlying AspectJ.
However, I think it would be very appropriate to allow args to let you bind certain arguments to an array or collection, e.g., (.., Type, ..) could be bound to Type[] matches for ALL the matching parameters. This would provide the highly desirable property of letting one write advice that works on all parameters of a given type, as Ron desires.
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
> ------------Original Message-------------
> From: "DiFrango, Ron" <ron.difrango@xxxxxxxxxxxxxx>
> To: "'aspectj-users@xxxxxxxxxxx'" <aspectj-users@xxxxxxxxxxx>
> Date: Wed, Aug-27-2003 6:10 AM
> Subject: RE: [aspectj-users] Parameters
>
> Gregor,
>
> In thinking about this more, if I were the one writing the requirements, I
> would want the situation you pose below to have two (or more if that is how
> the method call is structured) matches. In my case, I am trying to do
> contract enforcement so there is nothing that I would not want to happen on
> all instances of that object. Personally, I think that this is a better
> limitation, if you will, than the current one because I must declare point
> cuts with every combination of parameters that I might encounter now and in
> the future. The other alternative is to enforce some form of arbitrary
> architectural standard that certain parameters must be in certain orders,
> etc. which I think becomes difficult at best. Furthermore, I believe that
> this defeats the purpose of cross-cutting concerns because now my code
> essentially know that it will be cross-cut in some manner.
>
> Maybe aspectj could provide some sort of mechanism to say I want to enforce
> this on all parameters or not.
>
> Thanks,
>
> Ron DiFrango
>
>
> -----Original Message-----
> From: Gregor Kiczales [mailto:gregor@xxxxxxxxx]
> Sent: Wednesday, August 20, 2003 1:22 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] Parameters
>
>
> As I recall, the issue with using .. more than once in an args pointcut is
> as follows:
>
> consider three pointcuts
>
> p1(SpaceShip s): args(s, ..)
> p2(SpaceShip s): args(.., s)
> p3(SpaceShip s): args(.., s, ..)
>
> and a method like:
>
> void collide(SpaceShip s1, SpaceShip s2) { <make a big flash> }
>
> Well p1 and p2 both match calls or executions of this method. But what
> about p3? Should it match? Should it not match? Should it match *twice*?
>
> Its not clear (at least to me). There are some interesting things you could
> do here, but figuring them out could take some time.
>
> Because not allowing more than one .. neatly avoids this problem, that is
> what we did. We weren't saying that was the right decision for all time.
> But I think it was right for 1.0.
>
> Note that this is NOT a comment on whether .., x, .. in the unambiguous case
> is useful. I think it is, and that's why we tried to figure it out. Its just
> a statement that the ambiguous case seems to interfere here.
>
> > -----Original Message-----
> > From: aspectj-users-admin@xxxxxxxxxxx
> > [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of DiFrango, Ron
> > Sent: Wednesday, August 20, 2003 9:54 AM
> > To: 'aspectj-users@xxxxxxxxxxx'
> > Subject: RE: [aspectj-users] Parameters
> >
> >
> > Wes,
> >
> > In thinking about the problem more fully, I see (in my humble
> > opinion) a
> > limitation (severe if you consider legacy systems) in the way aspectj
> > handles the arguments to methods in defining PCD. If you
> > look at the way it
> > works today, aspectj requires that if you have a need to pull
> > out on certain
> > parameters to a given method, you must define (and must
> > continue to require)
> > the order in which they are defined in order to expose them
> > to the advice.
> >
> > To give you an idea of where I am using this is that I want
> > to pull out all
> > the common argument/parameter validation rules that current
> > have scattered
> > all over the place in our code base with one central
> > validation service via
> > aspectj. If I am required to re-order the
> > arguments/parameters to these
> > methods I may end up touching somewhere around 300 to 400
> > classes. On the
> > flip side if I could pick-out the arguments any where they
> > exist I would
> > only have to affect 62 classes or the ones that have the
> > rules in them.
> >
> > Please let me know if I am wrong of off base with this assessment.
> >
> > Thanks,
> >
> > Ron DiFrango
> >
> >
> > -----Original Message-----
> > From: DiFrango, Ron
> > Sent: Wednesday, August 20, 2003 8:47 AM
> > To: 'aspectj-users@xxxxxxxxxxx'
> > Subject: RE: [aspectj-users] Parameters
> >
> >
> > Wes,
> >
> > Thanks for your answer and it does not work in 1.0 as that is
> > the version I
> > am on currently. Actually it was what I expected. I am
> > surprised that I am
> > one of the first to bring this up.
> >
> > I personally would like to see the ability to use multiple
> > wildcards in a
> > PCD. The main driver for me is that I am retrofitting old
> > code and I would
> > prefer to keep the pre-existing interfaces as much intact as possible.
> >
> > Should I submit a bug report on this?
> >
> > Thanks,
> >
> > Ron DiFrango
> >
> >
> > -----Original Message-----
> > From: Wes Isberg [mailto:wes@xxxxxxxxxxxxxx]
> > Sent: Wednesday, August 20, 2003 12:03 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] Parameters
> >
> >
> > args(.., ClassX, ..)
> >
> > should have worked in AspectJ 1.0, but, as Erik noted for 1.1,
> >
> > We did not implement the handling of more than one ..
> > wildcard in args PCDs (rarely encountered in the wild)
> > because we didn't have the time. This might be available
> > in later releases if there is significant outcry
> >
> > http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspect
> > j-home/doc/REA
> > DME-11.html#language
> >
> > I'm not sure if a bug would qualify as a significant outcry,
> > but it would be
> > a place others could chime in.
> >
> > (Also, it's a doc bug that ".." in args(...) is not better
> > documented. I
> > couldn't find it in either quick reference or the programming guide
> > semantics appendix; perhaps my search was bad.)
> >
> > A workaround for now is to test the args directly, perhaps
> > even in an if
> > pointcut:
> >
> > aspect A {
> > private static boolean hasArg(Class c, Object[] args) {
> > for (int i = 0; i < args.length; i++) {
> > if ((null != args[i]) &&
> > c.isAssignableFrom(args[i].getClass())) {
> > return true;
> > }
> > }
> > return false;
> > }
> > before() : ... && if(hasArg(ClassX.class,
> > thisJoinPoint.getArgs()) {
> > ...
> > }
> > }
> >
> > Obviously, that won't pick out a null ClassX arg, and it
> > can be expensive, depending on the rest of your pointcut.
> >
> > Wes
> >
> >
> > DiFrango, Ron wrote:
> >
> > > All,
> > >
> > > I could not find an answer to this in any of the old
> > postings. I have
> > > methods that take a common parameter. The problem is that
> > depending
> > > on the method call this parameter may be listed anywhere in
> > the method
> > > signature. So for example:
> > >
> > > public class ParametersInMethodCalls
> > > {
> > > public void example1(ClassX x, double I, String s)
> > > {
> > > }
> > >
> > > public void example2(int I, ClassX x, double d)
> > > {
> > > }
> > >
> > > public void example2(float I, String s, ClassX x)
> > > {
> > > }
> > > }
> > >
> > > My question is can I define a pointcuts that picks out all the above
> > > combinations without having to "code if you will" the different
> > > permutations possible? I have tried the following
> > > examples/permutations:
> > >
> > > pointcut examples(ClassX x) :
> > > execution(public * ParametersInMethodCalls.*(..))
> > > && args(.., x);
> > >
> > > ==> Afected example2
> > >
> > > pointcut examples(ClassX x) :
> > > execution(public * ParametersInMethodCalls.*(..))
> > > && args(x, ..);
> > >
> > > ==> Afected example1
> > >
> > > pointcut examples(ClassX x) :
> > > execution(public * ParametersInMethodCalls.*(..))
> > > && args(*, x);
> > >
> > > ==> Affect nothing
> > >
> > > The important thing to note is that all the methods I want
> > to pick out
> > > have the common input of ClassX, but there is an
> > indeterminate number
> > > of other parameters to these methods. Furthermore, I would
> > prefer to
> > > avoid having to change the underlying code as it affects a
> > large body
> > > of code.
> > >
> > > Thanks in advance,
> > >
> > > Ron DiFrango
> > >
> > >
> > **********************************************************************
> > > ****
> > > The information transmitted herewith is sensitive
> > information intended
> > only
> > > for use by the individual or entity to which it is addressed. If the
> > reader
> > > of this message is not the intended recipient, you are
> > hereby notified
> > that
> > > any review, retransmission, dissemination, distribution, copying or
> > > other use of, or taking of any action in reliance upon this
> > > information is strictly prohibited. If you have received this
> > > communication in error, please contact the sender and delete the
> > > material from your computer.
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> > >
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> > **************************************************************
> > ************
> > The information transmitted herewith is sensitive information
> > intended only
> > for use by the individual or entity to which it is addressed.
> > If the reader
> > of this message is not the intended recipient, you are hereby
> > notified that
> > any review, retransmission, dissemination, distribution,
> > copying or other
> > use of, or taking of any action in reliance upon this information is
> > strictly prohibited. If you have received this communication in error,
> > please contact the sender and delete the material from your computer.
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> > **************************************************************
> > ************
> > The information transmitted herewith is sensitive information
> > intended only
> > for use by the individual or entity to which it is addressed.
> > If the reader
> > of this message is not the intended recipient, you are hereby
> > notified that
> > any review, retransmission, dissemination, distribution,
> > copying or other
> > use of, or taking of any action in reliance upon this information is
> > strictly prohibited. If you have received this communication in error,
> > please contact the sender and delete the material from your computer.
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> **************************************************************************
> The information transmitted herewith is sensitive information intended only
> for use by the individual or entity to which it is addressed. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
