Re: [aspectj-users] thisJoinPoint.getThis() documentation

[DAVID SUAREZ <davidsuarez@xxxxxxxxxxxxx>]

Thanks.  I've read the documentation but it didn't "gel" fully yet.  The
getTarget() Matthew mentioned is great as well since it is what I needed.

Since I'm new I've been seeing some code samples that have been posted
around and I've seen a couple of instances now where the pointcut includes a
!within(currentAspect).  Is this a best practice to avoid future un-intended
behavior where the aspect is trapped or is this something that should only
be placed if the pointcut is general enough that the aspect itself will be
caught by it?  This is just a best practice question for coding standards,
is it worthwhile to enforce setting the exclusion of the current aspect when
defining pointcuts?  Are there any other best practice web sites out there
for structuring aspect based code?  I'm starting to see cases where
pointcuts can be re-used across aspects technically but in terms of object
orientation, the goal of each object is completely different.  Therefore
it's creating redundancy that should be factored out but I'm not sure how to
structure the pointcuts in the most maintainable way.  For example:

I have an aspect called Logging.aj which does some logging.  One of the
pointcuts defined logs database calls.  I have a validation aspect which
tests that our standards are being followed.  It needs to capture the
non-std database calls (database calls except those defined in the logging
aspect).  However, it makes no sense for Validation to refer to a pointcut
in a Logging aspect so it should be moved out naturally.  This leads me to
think that there must be some best practice to organizing the code.  Is
creating pointcut libraries the best way to handle this and then the using
various aspects to join together the utility pointcuts as needed for their
behaviour?  Would there be a different issue if I did it that way?  For
example:

DBCalls-  Defines database related pointcuts only
Logging and Validation use/aggregate pointcuts defined in DBCalls and call
their own methods?

If no one sees an issue with doing it as above, do you have suggestions on
what the aspect utilities should be structured after?  Tiers in an
application (ie. database, middle tier, front end)? or something more
granular or cross-cutting (ie. security, caching, etc)?

Appreciate all of your assistance.  Seems the more I use this technology the
more I appreciate it.  Hopefully I'll be more knowledgeable soon.

Regards,

David Suarez

----- Original Message ----- 
From: "Wes Isberg" <wes@xxxxxxxxxxxxxx>
To: <aspectj-users@xxxxxxxxxxx>
Sent: Tuesday, January 27, 2004 6:53 PM
Subject: Re: [aspectj-users] thisJoinPoint.getThis() documentation


> "this" at a call join point is the caller, not the callee,
> because the caller is the currently-executing class/object.
> See "State-based pointcuts" in the Programming Guide Semantics
> appendix and also "join point shadow kinds" in Erik/Jim's paper:
>
>    http://hugunin.net/papers/aosd-2004-cameraReady.pdf
>
> Use "target(Callee)" if that's what you want.
>
> Wes
>
> P.S. - and remember: interception is a misconception;
> join points, pointcuts, advice...
>
> David.Suarez@xxxxxxxxxxx wrote:
>
> > Hello all,
> >
> > I'm trying to understand the reason for this behavior though it is
working
> > as documented....  I am running some code in a join point that occurs in
an
> > object that must be instantiated.  The method that is getting
intercepted
> > is not a static method but the caller is a static method in some cases
but
> > not in others.  In the case where the caller is a static method,
> > thisJoinPoint.getThis() returns null (as documented).  It seems that the
> > getThis() should be able to return the object in use even if called by a
> > static method if the method itself is not static.  However this is not
the
> > case as documented.  Any reason why since the object must be
instantiated
> > within the static method and therefore this is a currently executing
real
> > object?  Doesn't the byte code weaving just insert/pass a "this"
reference
> > which would be valid in java?  Makes sense for a static method but not
sure
> > why it's the case for a static method calling objects.  I am running in
> > threads from a J2EE app server presently, but does this mean that if I
have
> > a plain java application which start from a "public static
String(String[]
> > args)" I would never be able to use getThis() after the program starts
> > unless I spawn new threads?
> >
> > I would appreciate any insight into why this is the case or if it really
> > needs to be the case (ie. can this be a feature request?).
> >
> > Thanks...djsuarez
> >
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users