Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-dev] Re: [aspectj-users] Webapp development and AJ

Moving to aspectj-dev as I'm going to get a little under-the-hood:

On 10/03/06, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx > wrote:

How does adding code that matches a cflow test or that might otherwise be munged (advised) affect the generated method names?

I mentioned the percentage 99.99%.  The 0.01% is cflow - there is a situation I'm aware of with cflow where the order of weaving can produce different results.  But I always said I wouldn't look into it until it was reported as a problem.  it is possible you are hitting this case...  if you can reliably get things to fail with cflow in the mix, I'd be interested in exploring if you are hitting this - possibly by giving you a patch that avoids the optimization that leads to it.  Maybe bring the failing case to AOSD and we can look at it there...

I will also take a closer look the next time I see recompilation breaking hotswap: I think it is typically when you change the advised code that things are incompatible, which is actually the case I care about the most. If I change a pointcut, I recognize there may be significant changes…


After firing off my note, it did occur to me that we've spent a lot of time on advice names - but less time on things like the names of methods created for if() or the fields created for cflow.  Advice names are really strictly generated based on:

1. the advice kind
2. what number advice it is in the file
3. the hashcode of the pointcut

(this is in contrast to old aspectj where the name was based on the bytecode offset through the class ....!)
 
So...if you add more advice the names changes or if you modify the pointcut it changes.  if you simply change the body of the advice it should have no effect on the name.  Of course, if you add references to maybe thisJoinPoint or its relations, that will change the parameter signature of the advice.

I will also put some more effort into trying to isolate problems I've seen where weaving an –aspectpath aspect with cflow tests into a another class resulted in bytecode calls to private cflow methods in the aspect… it seems like it might also be related to this.

hmmm ... it does look like the 0.01% case ...

Andy.


Back to the top