Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Weaving code that comes from an Annotation's value 
Thanks for the additional suggestions. Very interesting to think
about. A few more options I forgot to mention are

1) Use Groovy, Jython, or JRuby to evaluate the expressions. I didn't
go this route, mainly to avoid requiring tests to be written in a
different language.

2) Use Barter, based on XDoclet annotations.

3) Use the design by contract aspect that's part of JBoss AOP (which
means adoption JBoss AOP, of course).

dean


On 2/4/06, Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> Three comments, to stir up this old pot...
>
> (1) if() pointcuts are evaluated before each join point, so you could do
>
>   before() : foo() && if(contractsEnforced && contract(thisJoinPointStaticPart)) {}
>
> This would be a terrible thing for many reasons, but it kind of works.  Instead of
> writing
>
>    @Test("test code here") void foo() {...}
>
> you'd write
>
>    void foo() {..}
>
>    @Test("execution(void Bar.foo())")
>    void fooTest() { ... }
>
> (2) perhaps (less terribly and sticking closer to AspectJ)
>
>    @Before("Contract4J.enforcing() && execution(void Bar.foo())")
>
> (look familiar?)
>
> And if you're nice about IDE integration, you can have
> - links back from fooTest() to foo() [free with @Before, soon?)
> - context menu item at foo() to create fooTest() and annotation.
>
> My design criterion for DBC is that the contracts need to be expressed in the
> programming language and get all the usual (IDE) support, so I much prefer
> associating code to developing a new domain language (which you can do using
> library API's).
>
> (3) The AspectJ AST is becoming much more usable, mainly driven by the desire to
> support refactoring, but someone could probably read comments or annotations
> during compilation, evaluate them using the standard compiler, and update the
> emitted code accordingly.  That give you all the power of Java in the expressions,
> and could work both in AJDT and on the command line.
>
> Cheers,
> Wes
>
> > ------------Original Message------------
> > From: "Michael Herrmann" <Michael_Herrmann@xxxxxx>
> > To: aspectj-users@xxxxxxxxxxx
> > Date: Sat, Feb-4-2006 9:04 AM
> > Subject: Re: [aspectj-users] Weaving code that comes from an Annotation's value
> >
> > Hi Dean,
> >
> > thank you very much for your detailed explanation. We've already talked
> > on
> > the SF.net forum of Contract4J where I suggested Contract4J V3, do you
> > remember? I'm asking this very question because I'm thinking about
> > writing
> > my own implementation of Design by Contract.
> > For this, I wouldn't want to use an expression evaluator, because I'd
> > like
> > to avoid the 'hassles' you mentioned. I'd rather write a preprocessor
> > that
> > generates .aj files in order to get around it.
> >
> >
> > Does anybody else maybe know of a possibility of how to achieve this
> > without
> > using a preprocessor?
> >
> > Thanks all
> > Michael Herrmann
> >
> > > This is pretty much what I do in Contract4J
> > > (http://www.contract4j.org), where the @Pre annotations triggers
> > > before advice. In this case, the value of the annotation is a java
> > > expression and it is evaluated with Jakarta Jexl's expression
> > > evaluator.
> > >
> > > I'm actually talking about the newest version that I am finishing,
> > not
> > > the two previous releases on the website. (ETA for the new release is
> > > ~1 week).
> > >
> > > Writing the aspect is not difficult. Evaluating the expression is
> > > harder, depending on how "sophisticated" it needs to be.
> > >
> > > Concerning the expression in the annotation value, does it vary with
> > > each usage of the aspect or is it fixed? Your example suggests you
> > > want to do tracing, but maybe that's just the example. If you have a
> > > fixed java expression or one that varies in "simple" ways, it would
> > be
> > > far easier to omit it from the annotation and put it in the aspect
> > > itself.  Consider the tracing aspect and ignoring the
> > > thisJoinPointStaticPart.toString() method ;), you could write tracing
> > > advice that does something like this:
> > >    before(Object o, <other args>): mypointcut(o,<...>) {
> > >      System.out.format ("class name = %s, stuff = %s",
> > > o.getClass().getName(), ...);
> > >    }
> > > Even if the expression changes a lot, maybe it would be simpler to
> > > write a base aspect and override it for each class/method, where the
> > > advice for class "Foo.foo" contains the expression. I'm just trying
> > to
> > > save you the hassles of integrating an expression evaluator, having
> > > gone through that pain myself, if you don't really need it.
> > >
> > > Actually, it wouldn't be that bad if your expressions don't require
> > > access to local context data, like Foo fields or methods. The pain
> > > comes in setting up Jexl's context correctly.
> > >
> > > So, with that digression, the aspect would be something like
> > >
> > > aspect BeforeExecutor {
> > >   pointcut execBefore (Object o, ExecuteBefore eb):
> > >     execution(@ExecuteBefore * *.*(..)) && this(o) &&
> > @annotation(eb);
> > >
> > >   before (Object o, ExecuteBefore eb): execBefore (o, eb) {
> > >     evalExpression(eb.value());
> > >   }
> > >
> > >   void evalExpression(String expr) { ... }
> > > }
> > >
> > > Of course, "evalExpression" is the hard bit.
> > >
> > > I can send you a preview of the newest C4J if you'd like to see what
> > I
> > > did with Jexl. In my case, I need to do some fancy footwork to setup
> > > Jexl's "context" for evaluating the expression. It can be done!
> > >
> > > Good luck,
> > > dean
> > >
> > > --
> > > Dean Wampler
> > > http://www.aspectprogramming.com
> > > http://www.newaspects.com
> > > http://www.contract4j.org
> > >
> > >
> > > On 2/4/06, Michael Herrmann <Michael_Herrmann@xxxxxx> wrote:
> > > > Hi,
> > > >
> > > > I'd like to be able to annotate my methods with code that should
> > then
> > > always
> > > > be called before the method itself is called. Is it, through
> > AspectJ,
> > > > possible to treat the value of a (String) element of an annotation
> > as
> > > code?
> > > >
> > > > For example:
> > > > public interface Foo {
> > > >         @ExecuteBefore("System.out.println('hi');");
> > > >         public void foo();
> > > > }
> > > >
> > > > I now want System.out.println('hi') to always be called before the
> > > > implementation of foo() is called. You might recommend using
> > abstract
> > > > classes in this case, but this is just an extremely oversimplified
> > > example
> > > > to show you what I mean and using abstract classes or anything
> > similar
> > > won't
> > > > help me, unfortunately.
> > > >
> > > > Thank you very much for your time
> > > > Michael Herrmann
> >
> > --
> > Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> > Satte Provisionen fr GMX Partner: http://www.gmx.net/de/go/partner
> > _______________________________________________
> > 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
>


--
Dean Wampler
http://www.aspectprogramming.com
http://www.newaspects.com
http://www.contract4j.org

Back to the top