[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Annotations AspectJ questions
|
Its going to take me a bit of time to digest technical portion of your
reply, so first Thanks!!!
I figured I'd address, at least the philosophical issues. Yes, I am
unable to alter our current tools strategy and avail the group of AJDT.
The philosophy driving the need for target annotation is a belief that
orthogonal concerns do indeed cross eachother and therefore, there
exists a point which represents an intersection of concerns that is
jointly owned by both the target and the aspect.
As the project I'm involved with has a fairly large number of
contributors, all attempting to bootstrap up a fairly complex project in
short order, we're faced with some of the realities involving a rapidly
shifting code base. As you point out, tools provide the ideal solution
for this, but failing that as a possibility, we'd like to provide a
known methodology, even if it is purely enforced by conventions, to at a
miminum indicate in the code being crosscut that its happening. As this
is a distributed computing project and highly parallelized, what might
seem unnecessary to some, is requisite in our case. One man's paranoia
is another's good practise. ;-)
BTW, thanks Adrian, I am already using showWeaveInfo, but again, our
engineering team would like to forge more of a contract (think
interface) between the two parties, which goes a bit deeper than
post-compile information.
Again, thanks all!
=Ron=
Wes Isberg wrote On 02/02/06 14:12,:
>Hi Ron -
>
>
>
>>Is there a prescription (at least by enforcing
>>conventions) for being able to annotate Class C,such
>>that:
>>
>>
>...
>
>Something like this?:
> after() returning : pc() && aspectsPermitted() &&
> codeExecutionPermittingAfterReturning() { ... }
>
>where the *Permit* pointcuts are defined in terms of
>annotations
>scattered through the possibly-affected code. That's
>doable (code below)
>but perhaps not desirable.
>
>Your question is whether clients should be oblivious or
>unwilling,
>and more generally the steps to take when adopting AspectJ
>in the
>face of doubt and a restricted tool environment.
>
>Just to be clear, AspectJ takes a three-step approach:
>(a) aspects should see and be able to affect everything,
>because
> crosscutting by nature affects other modules;
>
>(b) it's essential when working with crosscutting to have
> proper tool/IDE support for navigating the
>crosscutting,
> in order to understand any interactions (usually to
>convince
> oneself that there are no bad interactions).
>
>(c) the crosscutting language is expressive enough to be
>able to
> protect anything it can affect (but does not possess a
> macro-style ability to affect the language itself,
>because
> that adds too much complexity)
>
>So we took the path of believing clients are neither
>unwilling
>or oblivious when the programmer has notice and can change
>the aspect.
>You instead are requiring notice and consent, not for the
>aspect
>programmer in the aspect, but for the programmer of the
>affected code
>in the affected code.
>
>By hypothesis in your case, the programmer of the affected
>code is
>permitting *some* crosscutting (but wants to control it?),
>is
>unable/unwilling to use the tool support to get notice,
>and wants control via annotations. This comes largely from
>the
>promise of annotation-style aspects to make it easier to
>integrate
>AspectJ, and shows that we have not provided the tool
>support necessary
>for annotation-style, particularly for people not using
>AJDT. We
>are working in AJDT to provide the same support for
>annotation-style
>as code style, and should offer command-line tools for
>those not
>able/willing to use Eclipse.
>
>Outside of AJDT, you can get some notice by using ajdoc.
> But what
>you'd want is a tool which, given a specification (e.g.,
>don't
>affect classes X, Y, or Z; don't use after-throwing
>advice), could
>signal when the rules were violated. Ideally, for each
>violation
>you'd want a reference to the violating advice or ITD,
>which
>likely means you'd build it on the crosscutting map
>generated by
>the compiler/weaver. (Helen's recent updates to the AST
>might
>make this a lot easier.) But the key benefit of this tool
>would be
>being able to write the (crosscutting) specification once
>and
>enforce it whenever and whereever. You'd still have the
>option of
>allowing the programmer of the affected code to scatter
>annotations
>by way of specification if that made them more comfortable,
>but
>you wouldn't have to litter the aspects with corresponding
>guards.
>
>Annotation guards are limited because they are not as
>expressive as
>pointcuts. They basically only help for policies applying
>class-wide
>or per-method or constructor execution or call or field get
>or set,
>and you still have to decide, e.g., whether to permit
>advice on a
>(anonymous?) subclass of a class annotated to refuse
>advice.
>
>So, now that you've suffered my lecture on why you don't
>want to do
>this, here's a sample of what you'd have to do:
>
>--------------------------------------------
>package stuff;
>
>public class ExecPlus {
> public static void main(String[] args) {
> new C().foo(0);
> new D().foo(0);
> }
>}
>@interface AfterOK{}
>@interface NoAspects{}
>
>abstract class B { abstract void foo(int i); }
>class C extends B { public void foo(int i) {} }
>class D extends B { @AfterOK public void foo(int i) {} }
>@NoAspects class E extends B { @AfterOK public void foo(int
>i) {} }
>aspect A {
> pointcut pc() : execution(void B.foo(int));
> pointcut codeExecutionPermittingAfterReturning() :
> execution(@AfterOK *.new(..))
> || execution(@AfterOK * *(..));
>
> // have to add guards to each advice
> after() returning : pc() && aspectsPermitted() &&
> codeExecutionPermittingAfterReturning() {
> System.out.println("here: " + thisJoinPoint);
> }
> // implementing @NoAspects - could be in execution,
>like
> // !execution(* (@NoAspects *).*(..))
> // but we'd like to define aspectsPermitted() for other
>join points
> // (have to work around "type patterns not permitted in
>target()")
> private interface NA {}
> declare parents: (@NoAspects *) implements NA;
> pointcut aspectsPermitted() :
> !within(NA+) && !target(NA);
> // could be !within(@NoAspect *)
>}
>-------------------------------------------------------
>
>This is basically your solution:
>
>
>
>> @BeforeOnly @AfterOnly
>> public void doIt() {...}
>>
>>
>
>If you just want a way to state class- or package-level
>control
>without littering the code with annotations, you can
>instead use
>declare parents or repeat a type pattern:
>
> interface NIMBY {}
> declare parents: (com.co.special..*) implements NIMBY;
>
>Then use NIMBY as NA was used above. In this case, the
>rule
>holds even if someone forgets to add or remove an
>annotation.
>
>But your requirements here are a bit broader:
>
>
>
>>A) The developer of C will know that an aspect has been
>>applied
>>B) The developer of C will know (and by convention limit)
>>the style of aspect applied
>>C) The developer of A can not add a pointcut unbeknownst
>>to the owner of C (without at least violating
>>conventions)
>>
>>
>
>(A) There is no way to meet (A) given your tool setup. For
>C to know,
>s/he has to use some of our tools.
>
>(B) We satisfy the C-developer's knowledge in AJDT, and
>could do
>more in another reporting tool, but to permit the
>C-developer to
>limit the A-developer (without A's knowledge?) involves
>creating a
>whole new language about the AspectJ crosscutting language.
> As you
>suggest, you can go down this road with some
>annotation-based
>conventions, but annotations are not powerful enough.
> Again, a tool
>might help. (And what would drive a tool would be a nice
>clean
>specification of what it's supposed to do and why - a good
>use case.)
>
>(C) *Restricting* A-developer means getting AspectJ
>language support
>for not using the AspectJ language - it's just weird. You
>can do that
>by not using the language, i.e, not weaving the class.
>You're welcome
>to adopt the annotation conventions, but they won't be
>enforced.
>
>There have been proposals that extending a pointcut be
>limited to
>restricting the original pointcut; that would enable
>abstract aspects
>to enforce a policy against subaspects. There's also a
>proposal to
>not weave final classes by default. But that's not how it
>works now,
>in part because the solutions are partial and just confuse
>the clear
>rule that aspects see/do everything.
>
>I suspect the requirements are over-broad. C-developers
>have a vague
>concern that the aspect -- i.e., some other developer --
>might do
>something-they-know-not-what. If C-developers don't trust
>the
>A-developers, there's not much the tool can do. If they
>are just
>concerned about accidents, then they might be convinced by
>showing
>that AspectJ offers basically the same protections as Java
>wrt type-
>and exception- safety and checking.
>
>C-developers might also gain confidence against accidents
>and
>incompetence if A-developers can use AJDT to double-check
>their work.
>So I'm curious why you can't use binary aspects written in
>code style.
>Annotation-style aspects do use the AspectJ syntax, but
>they just defer
>the processing until they are woven. With either
>code-style or
>annotation-style, you need to do a weave (so the build or
>class-loading process has to change). Code style has much
>better
>support in AJDT, and AJDT also helps new developers learn
>AspectJ,
>leading to better A-developers.
>
>enough said!
>
>hth - Wes
>
>On Thu, 02 Feb 2006 08:50:28 -0500
> Ronald J Mann <Ron.Mann@xxxxxxx> wrote:
>
>
>>Hi all!
>>
>>Another newbie question. After scanning the docs, I'm a
>>little confused
>>on the capabilities of annotations. I'm trying to employ
>>aspects as a
>>part of a broader project, some of whom's members are
>>quite suspicious
>>of granting the ability to crosscut their code without
>>they're explicit
>>knowledge embodied in their code. Equally, I've been
>>required to use
>>the annotation style for my poincuts and advice as the
>>result of the
>>build process issues around utilizing the aspectJ syntax
>>directly.
>>
>>I've successfully used the annotation style for the
>>pointcuts and
>>advice declarations themselves, but I'm teetering on the
>>brink of
>>understanding as to the use of annotations in the body of
>>the code that
>>is to be cut. Before I proceed down this road, I wanted
>>to confirm that
>>one can concurrently employ annotations for both the
>>advice declaration
>>as well as pointcut discrimination. So given something
>>that currently
>>looks like this:
>>
>>class C {
>> public void doIt() {...}
>>}
>>
>>@Aspect class A {
>> @Before("call(void C.doIt())") { ... }
>>}
>>
>>Is there a prescription (at least by enforcing
>>conventions) for being able to annotate Class C,such
>>that:
>>
>>A) The developer of C will know that an aspect has been
>>applied
>>B) The developer of C will know (and by convention limit)
>>the style of aspect applied
>>C) The developer of A can not add a pointcut unbeknownst
>>to the owner of C (without at least violating
>>conventions)
>>
>>thus if I had created a BeforeOnly & AfterOnly
>>annotation:
>>class C {
>> @BeforeOnly @AfterOnly
>> public void doIt() {...}
>>}
>>
>>What would the syntax for the aspect look like?
>>@Aspect class A {
>> @Before("???????") { ... }
>>}
>>
>>Would there be a methodology to actually restrict the
>>application of an @AfterReturning?
>>I recognize that some of these notions might be outside
>>the spirit of AOP/aspectJ, but having to deal with real
>>world resistence to AOP is a part of the equation.
>>
>>Thanks in advance for the 'advice' ;-) !
>>
>>=Ron=
>>
>>
>>
>>
>>
>>_______________________________________________
>>aspectj-users mailing list
>>aspectj-users@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
