[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Annotations AspectJ questions
|
Thanks Matthew!
Sorry, I didn't mean to imply that ability to crosscut was purely in the
hands of the code being weaved, rather more what you've suggested. The
notion of a @BeforeOnly is provided by the aspect developer in the code
being crosscut as indication to the primary concern developer that this
is how the code is being crosscut and as a definition of the current
control flow contract between the parties. This is purely so the code
owner of the primary concern understands what is going on. Equally, I'd
like to enforce from the advice side that that is what in fact is going
on. That if a method is declared @BeforeOnly, then the advice writer
would be forced to supply an @AfterReturningOnly, if they find a need to
add a new crosscut. I view this, not as adversarial, rather as a form
of type checking, simply to ensure that everything happens in the open.
So I think, given your remarks below we're pretty much on the same page.
Thanks for your example, I think it clarified what I want to do which is
purely advisory as its only enforced by conventions on the part of the
aspect developer. Something like this:
public class C {
@BeforeOnly()
public void answer(int i) {
System.out.println( i );
}
}
@Aspect
public class A {
@Before( "call(@BeforeOnly void C.answer( int )) && args( i )" )
public void question( int i ) {
if ( i == 42 ) {
System.out.println("What is 6 x 9?");
}
}
}
So while this doesn't prevent a declaration without the @BeforeOnly in
the crosscut, it establishes a convention for our usage which I think
can satisfy all parties. .
Thanks again all!
=Ron=
Matthew Webster wrote On 02/03/06 06:24,:
>
> Ron,
>
> It is understandable that developers will be concerned about the
> affect aspects will have on their code, particularly if they feel they
> will be responsible for any bugs that may result from weaving. However
> the approach you suggest will do nothing to promote trust and because
> it is tantamount to putting up fences and may in general cause as many
> problems as it tries to solve. This is because an aspect may be
> excluded from advising certain join points which may be necessary for
> its proper function. The resulting program will be incorrect and
> difficult to debug.
>
> A better approach is to use annotations as a way of defining the
> contract between code and aspects rather than a series of "Keep Out"
> signs. This works better for some aspects than others. For example to
> apply a Java 2 security mechanism developers would add an @Permission
> annotation:
>
> public class HelloWorld {
>
> @Permission("print")
> public void println() {
>
> System.out.println("Hello World");
> }
>
> public static void main(String[] args) {
> HelloWorld hello = new HelloWorld();
> hello.println();
> }
> }
>
>
> allowing you to use the following aspect:
>
> public aspect SecuritySupport {
>
> before (Permission p) : execution(@Permission * *(..)) &&
> @annotation(p) {
> SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(new
> HelloPermission(p.value()));
> }
> }
>
> }
>
> public class HelloPermission extends BasicPermission {
>
> public HelloPermission (String action) {
> super(action);
> }
> }
>
> One place where exclusive rather than inclusive annotations can be
> used is with tracing aspects. Here using @Exclude can be used to
> ensure certain methods or classes are not traced either because too
> much data is produced or sensitive information would be exposed. In
> this case it is not misleading because when an entry is missing from
> the log it is obvious why.
>
> In the long run AOP will only work in your project if everyone thinks
> it's a good idea. This doesn't mean everyone has to understand how to
> use it, at least not initially, but they have to benefit. This will be
> difficult if you start from a position of using annotations to defend
> code against aspects.
>
> Matthew Webster
> AOSD Project
> Java Technology Centre, MP146
> IBM Hursley Park, Winchester, SO21 2JN, England
> Telephone: +44 196 2816139 (external) 246139 (internal)
> Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
> http://w3.hursley.ibm.com/~websterm/
>
> Please respond to aspectj-users@xxxxxxxxxxx
>
> Sent by: aspectj-users-bounces@xxxxxxxxxxx
>
> To: aspectj-users@xxxxxxxxxxx
> cc:
> Subject: [aspectj-users] Annotations AspectJ questions
>
>
> 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
>
>
