[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