[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] FindBugs error in abstract aspect that uses pertypewithin
|
> Should'nt the aspectj compiler/weaver be reporting at least a warning in the case that an abstract aspect is adviced by a concrete sub-aspect?
In your situation, i can see a warning would have been useful. But
other people may be expecting it to advise the abstract aspect in
another scenario and the warning would just be annoying. I can
imagine an Xlint that can be switched ignore/warning/error but I am
not sure what the default would be.... However, I think the problem
here stems from your second point:
> What makes this worse is that in the larger project where I first found this issue, neither the advice markers or crosscutting visualization view show anything to indicate that advice defined in concrete sub-aspects apply to the abstract parent aspect.
That sounds like a bug. When i compile your example on the command
line with -showWeaveInfo, I see that both your types are being
advised. I haven't tried it in AJDT yet, to confirm the
relationships are not showing up. If your concrete and abstract
aspects are in different projects, I can imagine this not showing up
as we are a bit weak in that area - but if they are in the same
project, it seems like a bug. We have open issues relating to how to
show concrete/abstract aspect relationships, see bugs like
https://bugs.eclipse.org/bugs/show_bug.cgi?id=78615 . I'm not saying
this is your bug, but it does indicate a current problem we have with
reflecting the weaving of concrete/abstract aspects in the UI.
Andy.
On 08/12/2007, Bhaskar Maddala <maddalab@xxxxxxxxx> wrote:
> Hello,
>
> I have an abstract aspect, where I define my point cuts, and 2 derived
> concrete aspects that use the pointcuts to implement advice. On building in
> eclipse and running findbugs I get the following bad practice bug
>
> Superclass uses subclass during initialization.
>
> I used jclasslib to look at the byte code and I can see that the abstract
> aspect had references to the concrete aspects. The reason was a overly broad
> definition of pertypewithin. Below is a toy code sample that results in this
> findbugs error
>
> package bar;
>
> public abstract aspect AbstractAspect pertypewithin(bar..*)
> {
> pointcut loginitialization() : staticinitialization(bar..*);
> pointcut loggedMethods() : (within(bar..*)) && execution(* *.*(..));
> }
>
> package bar;
>
> import java.util.logging.Level;
> import java.util.logging.Logger;
>
> public aspect ConcreteAspect
> extends AbstractAspect
> {
> after() : loginitialization() {}
>
> before() : loggedMethods() {}
>
> after() : loggedMethods() {}
> }
>
> The AbstractAspect satisfies the pertypewithin scope and is advised by
> ConcreteAspect.after():loginitialization
>
> My Question : Should'nt the aspectj compiler/weaver be reporting at least a
> warning in the case that an abstract aspect is adviced by a concrete
> sub-aspect? What makes this worse is that in the larger project where I
> first found this issue, neither the advice markers or crosscutting
> visualization view show anything to indicate that advice defined in concrete
> sub-aspects apply to the abstract parent aspect. Though they seem to work on
> my toy example. Trying to track down the reason for the warning using
> FindBugs is difficult since the byte code does not translate as easily to
> aspectj code.
>
> Thanks
> Bhaskar
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>