[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-dev] Re: [aspectj-users] Webapp development and AJ
|
Hi Andy!
I cannot confirm it yet, but it looks like some of the latest builds are breaking the previous assumptions.
While using an AJDT from February and fixing my stupid mistake about reloadable context things started to look quite cool.
I have upgraded meanwhile to ajdt_1.3.1.20060310112556 and right now
the JVM is complaining about impossibility to hotswap almost all the
time (even if I do not modify the signatures, or things that are
considered to break the hotswap mechanism).
Do you know of any changes that might have lead to this?
cheers,
./alex
--
.w( the_mindstorm )p.
On 3/10/06, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
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.
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev