[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] JoinPoint SourceLocation vs. Stack Trace Interigation
|
"Using thisJoinPointStaticPart will avoid the run-time creation
of the
join point object that may be necessary when using thisJoinPoint
directly"
Wes
Gregory> It is my understanding that the use of JoinPoint is a
Gregory> reflective operation. [...]
Have you considered using `thisJoinPointStaticPart'?
Eric.
Cool. Got it. Using it. Works great. Here's the quandary: How is
the JoinPoint static data obtained?
Prior to JoinPoint, I was unaware of any other Java mechanism to
obtain file location information beyond the stack trace. If
JoinPoint is using a stack trace to fill out it's data, why not just
do it myself? I am of course assuming that if I leave off the
JoinPoint arg, I won't incur the JoinPoint data-gathering hit... IOW:
If I do this,:
@After("call (net.kedges.Foo+.new(..))")
public void fooCreatedHere() {
System.out.println("Foo created here: " + new Exception
().getStackTrace()[1].toString());
}
in lieu of this:
@After("call (net.kedges.Foo+.new(..))")
public void fooCreatedHere(JoinPoint.StaticPart
thisStaticJoinPoint) {
final SourceLocation sl =
thisStaticJoinPoint.getSourceLocation();
final StringBuilder sb = new StringBuilder(sl.getWithinType
().getName());
sb.append('(').append(sl).append(')');
System.out.println("Foo created here: " + sb.toString());
}
I won't generate the JoinPoint data, static or otherwise, because I
used a signature that didn't require it (BIG ASSUMPTION) and I will
be doing the exact same process that is performed within the
JoinPoint. I would tend to agree with anyone that contend that using
JoinPoint is consistent and familiar in the writing of aspects even
if JoinPoint employed stack traces...
Sorry if I am over obsessing on this but, asking helps me learn AND
move on... :-}
Greg K.
gregATkedgesNOSPAMcom
