Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
why not extend concrete aspect - was Re: [aspectj-users] Some questions/suggestions about AspectJ

> why isn't possible to
> extend concrete aspects.

There are probably many reasons for this.  The first I can
think of is that when the weaver gets a concrete aspect, it
knows that it has the complete aspect definition.
 Otherwise, it has to search around for things.  The rules
for precedence and applying aspects would be quite
interesting if a concrete aspect were applied and then
another came alone to reapply it.  The original would still
be effective.

As for your workaround, you might consider an alternative I
put in the AspectJ sandbox a couple years ago.

It uses the static scope search rules to modify the
definition of a pointcut at compile time.  It works by
putting the default pointcut definitions in a superclass.
 Without more, the extending aspect (concrete or aspect)
picks up the defaults.  But you can modify them at
weave-time by using declare-parents to interpose a new
superclass with new pointcut definitions, which are picked
up first when the pointcut name is resolved by going up the
type hierarchy.  That's different than extending concrete
aspects because the redefinition is known at the time the
subaspect is resolved.  


On Thu, 15 Jun 2006 21:38:49 +0100
 Paulo Alexandre Corigo Zenida <paulo.zenida@xxxxxxxx>
> Hello there,
> I have a few questions and suggestions that I would like
> to share with the AspectJ community.
> First of all, I would like to know why it isn't possible
> to inject exceptions in methods. I know it is not
> possible to make an advice throw an exception other than
> the ones in the contract of a method, which makes sense.
> However, why can't we make a method, annotated with a
> certain annotation, for example, throw a checked
> exception, through ITD? I am working on my master degree
> thesis project, about access control, and I am using
> annotations to specify the points in the code that
> require some kind of permission. This way, I am doing
> something like this on methods:
> @AccessControlled(requires = "foo")
> public void foo() {
>   ...
> }
> In order for client code to be able to deal with the lack
> of permissions by the principals, I would like to make it
> possible to throw a checked exception (at the moment, I
> am just throwing an unchecked exception, which is not
> what we want here!). Shouldn't this be possible?
> Something like:
> declare throws :
> AccessControlException;
> Second: I would also like to know why isn't possible to
> extend concrete aspects. I have one situation in which I
> would like to make the aspect application mandatory (a
> concrete aspect) but, at the same time, make it possible
> to "refine" the pointcuts definitions in it (an abstract
> aspect). More concretely, I have created an aspect which
> enforces some policies, which must always be applied.
> However, I would like to make it possible to switch from
> warning to error messages, as wanted. Example:
> public aspect MyAspect {
>   public final pointcut all() : !none();
>   public final pointcut none();
>   public pointcut declareWarningScope() :    all();
>   public final pointcut declareErrorScope() :
>    !declareWarningScope();
>   declare warning :    declareWarningScope() && ... :
> "Warning: Blabla";
>    declare error :    declareErrorScope() && ... :
> "Error: Blabla";
> }
> This aspect should always be applied but I would like to
> make it possible to redefine the declareWarningScope()
> pointcut. However, I cannot extend that aspect so I have
> a problem! To fix this, I have created a workaround,
> together with my thesis advisor (Manuel Menezes de
> Sequeira), which I would like to share and, maybe, get
> some feedback about it.
> The idea is that we put the pointcuts definitions (the
> declareWarningScope and declareErrorScope pointcuts) in a
> class, which the aspect extends (not an interface so that
> the declareErrorScope() can be final):
> public abstract class MyClass {
>    public pointcut declareWarningScope() :
>    mypackage.AnAspect.all();
>   public final pointcut declareErrorScope() :
>    !declareWarningScope();
> }
> public aspect MyAspect extends MyClass {
>   declare warning :    declareWarningScope() && ... :
> "Warning: Blabla";
>    declare error :    declareErrorScope() && ... :
> "Error: Blabla";
> }
> Then, when we make the project available for others, we
> create two JAR files: one with everything, except the
> class MyClass, jar-base.jar, and another one with just
> the class MyClass, jar-ext.jar.
> When we want to refine the pointcuts definition, we don't
> use the second JAR, which will cause a compile time
> error, due to the unexistence of the class MyClass. That
> forces the user to create that class in the specified
> package, where he may define the pointcut as wanted. If
> he does not want a redefinition of those pointcuts, he
> simply uses both JAR's. What do you think about this
> solution? Is there one better for this problem?
> Finally, I am using annotations in packages to declare
> the permissions for all members of that same package.
> This way, I try to verify if the permission requirements
> for a certain method have been declared or not in a
> certain class or package. However, when those are
> declared in packages, I cannot guarantee that the package
> have been actually loaded: only if a class in that
> package have been loaded, right? This way, I force a
> class to be loaded in a certain package. The convention
> was that one aspect in my project, when instantiated, is
> passed a list of classes that should be instantiated, so
> that the packages and their annotations are loaded and
> stored in that aspect. However, if we have a class A in
> the package pt.iscte but no class in the package pt, the
> package pt will not be recognized. So, my question is:
> would it be possible to use AspectJ to declare classes on
> packages? If that would be possible, I would not have to
> create a class myself but I could use AspectJ to create
> it, and then pass it to that Aspect that loads the
> classes.
> I hope I have made myself clear and sorry for the mail
> size...
> Thanks for your attention and interest.
> Cheers,
> Paulo Zenida
> Mensagem enviada usando o IMP (Internet Messaging
> Program).
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx

Back to the top