[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ajdt-dev] AspectJ / AJDT -- what is stable?
|
Hi,
On the bug:
I've an idea on the NPE but can't seem to trigger it. I believe it to be an interplay between two things:
1) I modified the model search code to more rapidly locate types in a package
2) I added nodes to the model for import statements.
I suspect somewhere there is an import statement being incorrectly recognized as a type. But I can't seem to find the sweet spot that will trigger what I believe to be the failure path. I'll keep trying.
Things that might trigger this probably include static imports - we don't have many tests for that.
Once I can trigger it, I'll fix it in a few moments, but I want to see it go wrong first. Getting the fix to you may be trickier - but if you were OK with 1.6.2 we are looking to resurrect the update site for it, enabling you to run with AspectJ Compiler 1.6.3 release and the AJDT 1.6.2 final release.
> AJDT works rather half-way satisfactory for us
The imminent focus for us is to address all the glitches that cause AJDT and AspectJ to be only half-way satisfactory for everyone. Most recently, for example, I've been fixing problems with incorrect cascading errors appearing when you make a minor typo. And the AspectJ included in AJDT 1.6.3 should do a much better job of incrementally compiling when ITDs are in the mix.
> But, on the other hand, since at least last Fall, the cross references view is unreliable, and this got
> significantly worse with AJDT 162. But this is really difficult to track
I've seen some of this, but I also find it difficult to track down. The compiler will always do the right thing and the woven code will be fine, but I know there are some issues with how that is reflected in the UI - this is unhelpful but until we can pin it down precisely, it is tricky to fix.
I would urge yourself and everyone to report any minor glitches as those are what we are looking to address now - don't just put up with problems any more. Even if you don't have a testcase it is worth letting us know as we can use some of our resource to investigate.
Andy.
2009/2/2 <
prg@xxxxxxxxxxxxxxx>
>
> Hi Andy,
>
> thanks for your quick response and the explanations; basically I am
> aware of the situation and appreciate your efforts.
>
> > If I were you, and you are happy with AspectJ 163 - I would continue
> > to use that as the released stable version. I'm suprised you didn't
> > see any of the problems we had raised about JDT weaving and AJDT1.6.2
> > - did you really find that a smooth experience?
>
> Compared with the versions *before* AJDT 162, this release felt a good
> deal more stable for me, especially the incremental build and the eager
> parser seemed to work more smooth. Generally speaking, AJDT works rather
> half-way satisfactory for us, but it has been improved significantly
> since Spring 2008.
>
> I don't know what the point of reference is for a "smooth experience".
> But at least in this new AJDT 163, I saw for the first time an
> (in-project) Aspect show up in the search list of "open type", while
> another Aspect from a neighbour project imported via Jar at least shows
> up as Class! Thanks for that! But, on the other hand, since at least
> last Fall, the cross references view is unreliable, and this got
> significantly worse with AJDT 162. But this is really difficult to track
> down; I didn't succeed with extracting a test case showing the problem
> (otherwise I'd reported already ;-)
>
> > This is the build you want
>
http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/aspectj-DEVELOPMENT-20090106235947.jar
>
> Thanks, this is vital information for us.
>
> I should shortly point out the situation. We have several projects,
> which get deployed onto several production systems. (Financial/Banking
> context). There is a formal testing and release cycle, so we can't just
> take on a new AspectJ version just because it makes AJDT more smooth.
>
> We have a strict policy that all builds need to work completely
> standalone with Ant from command line, and in our setup we need to
> use both aspectpath and inpath, because also our basic library jars
> contain some vital aspects. Classes get rewoven, signed for web
> distribution and so on. So, there are almost all the time classes
> included somehow, which get woven in an external build process,
> probably this also explains the sometimes shaky behaviour of AJDT.
>
> As we have to do continuously small improvements and fixes for
> production, it is really hard to get most of the team members
> to upgrade for a new release cycle. We are still using AspectJ 153
> in production. So my only hope is to find out a new version, which
> doesn't cause compilation or memory problems and also would allow
> to get all team members to use a single fixed AJDT version in near
> future, which works reasonably well. (and AJ 163 looked quite good
> for me up to now).
>
>
>
> > The key problem for you seems to be for us to resolve this new issue:
> ...
> > which I have never seen before. Send me an email with any more info
> > you have. I'll be taking a look right now to see what it is.
>
> In the current situation, I can reproduce it easily; I will now install
> the new AspectJ driver you pointed out to me and then try to recompile
> everything from scratch and re-build all jars. I'll report the outcome
> of this check immediately, say in about half an hour.
>
>
> The Aspect which is probably causing it is a well known culprit.
> Probably I wouldn't do it again this way, but it plays an important
> role in the system, because it automatically wraps a Service Locator.
>
> This Aspect is imported via our basic library Jars. It targets all
> calls to methods defined on certain business interfaces, which are
> marked by annotation.
>
> The error happens when incremental compilation kicks in after changing
> any class bearing the @BussFasade
>
>
> Note: we use hasmethod()
>
> Below is a shortened excerpt:
>
> public pointcut ServicePoint()
> : call( * (@BussFasade *).*(..) )
> && !@within(Clientside)
> && !@annotation(Clientside)
> && ( !@within(ServiceImplementation)
> || @withincode(Clientside)
> )
> ;
>
> declare @type
> : hasmethod(* (@BussFasade *).*(..))
> : @ServiceImplementation;
>
> public @interface ServiceImplementation { }
>
>
>
>
> private pointcut call_Servermethod(Object businessTarget)
> : ServicePoint()
> && target(businessTarget);
>
> Object around(Object bussFasade)
> : call_Servermethod(bussFasade)
> {
> .....
> }
> _______________________________________________
> ajdt-dev mailing list
>
ajdt-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
