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 
> 3) Use the design by contract aspect that's part of JBoss
> AOP (which
> means adoption JBoss AOP, of course).

Didn't someone write an adapter to run JBoss aspects
using AspectJ?  I didn't think you had to adopt JBoss
to use their aspects.

Wes

On Sat, 4 Feb 2006 12:16:12 -0600
 Dean Wampler <deanwampler@xxxxxxxxx> wrote:
> 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
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

Back to the top