[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] interfaces, pointcuts, and libraries

Hi all,
Hello Wes,

the current abstract pointcut behaviour is fine with me, asl long as I use it 
as a real abstract pointcut.

However I often have to abuse abstract pointcuts to emulate something what I 
have named extensible pointcuts. (One of my requests for 1.1)

I have the impression, that this feature would be give Adrian, all what he 
needs to implement and would fit more clearly into the language. Please tell 
me if I am wrong.

Unfortunatly I can imagine, that this causes some headache with incremental 
compile, weave. ...

Some motivations examples:

1. Exception logging.
I found very often a general rule, that all caught runtimeexception, which 
might have caused some harm, should be logged to stderr, ...

so following advice with pointcut would do it:

before(Exception ex):handler(Exception)&&args(ex){
   ex.printStackTrace(); // some other stuff...
}

It is pretty naturally to move this logic to a kind of library aspect. 
Unfortunatly, there are always some exceptions form the general rule in the 
code base. Places, where the advice should not be applied.

So I would like to say:

abstract aspect LogExceptions{

abstract pointcut mustNotLog();
before(Exception ex):handler(Exception)&&args(ex)&&!mustNotLog(){
   ex.printStackTrace(); // some other stuff...
}

So I can have one aspect per project, where I limit the scope for the library 
aspect. (with a concrete aspect).
In practical code, this causes a very ugly concrete aspect.

What I would prefere to have is something like:

abstract aspect LogExceptions{

extensible pointcut mustNotLog();
before(Exception ex):handler(Exception)&&args(ex)&&!mustNotLog(){
   ex.printStackTrace(); // some other stuff...
}
}

somewhere else:
declare pointcut LogException() extends: &&within(SomeClasss);

and somewhere else:
declare pointcut LogException() extends: &&within(SomeClasss);

This specific feature can be also used the other way round, motivated by my 
original post:
To add some joinpoint to an aspect. For this case I have found some idioms to 
work around, however I find them everything else than handy.
However for the case, where I want to exclude some joinpoints with extensible 
pointcuts I do not jet know a solution.

kind regards
   Arno


      
}





On Saturday 26 July 2003 23:09, Wes Isberg wrote:
> Another question is whether abstract aspects could play the same role.
> While extending aspects is less flexible, it has the property that
> the implementation is determinate for incremental weaving.
>
> Here's some pseudo-code for a programmer using a library of J2EE
> pointcuts that is implemented by different vendors.  The last step
> can be the selection of the vendor, when deploying:
>
> ------- pseudo-code...
> ---- AspectJ J2EE library
>
> abstract aspect EjbPointcuts {
>     abstract pointcut ejbInit();
>     abstract pointcut ejbActivation();
>     abstract pointcut ejbPassivation();
>     abstract pointcut ejbPersisting();
>     abstract pointcut ejbMessage();
>     ...
> }
> abstract aspect JmsPointcuts { ... }
> abstract aspect ServletPointcuts { ... }
> abstract aspect JSPPointcuts { ... }
>
> ---- {vendor} J2EE library
>
> abstract aspect VendorEjbPointcuts extends EjbPointcuts {
>      {define pointcuts}...
> }
> ...
>
> ---- programmer writes to AspectJ J2EE library
>
> abstract aspect BankTransactions extends EjbPointcuts {
>      Object around() : ejbMessage()
>          && call(void Account.deposit(int)) {
>          ...
>      }
>      ...
> }
>
> ---- application assembler/deployer hooks everything up
>
> aspect BankTransactionsAssembly extends BankTransactions {
>      declare parents: BankTransactions extends VendorEjbPointcuts;
> }
>
> ------- end of pseudo-code...
>
> This approach poses single-inheritance problems that might drive
> towards a single abstract aspect and deter reuse of other
> abstract aspects, so it's obviously not ideal.  It might lead to
> a practice of using the library pointcuts from other aspects:
>
> ----
> -- programmer code
> /** concretize the EjbPointcuts for use */
> abstract aspect BankTransactionPoints extends EjbPointcuts {
>      ...
>      public pointcut depositTransaction() : ejbMessage()
>           && call(void Account.deposit(int);
> }
>
> aspect BankTransactions extends Transactions {
>      /** concretize the abstract pointcuts in Transactions */
>      pointcut transactionalMessage() :
>          BankTransactionPoints.depositTransaction();
>      ...
> }
> -- application assembler/deployer
>
> aspect BankTransactionsAssembly extends BankTransactions {
>      declare parents: BankTransactionPoints extends VendorEjbPointcuts;
> }
>
> ----
>
> This approach localizes the pointcut definitions in the vendor aspect,
> which is loaded before any aspect or class that is affected by
> the aspect, so it preserves incremental load-time weaving.
> (Indeed, a vendor controlling the weaver could implement custom
> join points not based on the normal Java programming model without
> affecting the AspectJ language.)
>
> So before I'd want to support interface pointcuts that prevented
> implementations of AspectJ from doing incremental weaving, I'd like
> to see a few libraries using abstract aspects and know that they
> can't do what people would like to do with libraries.
>
> Wes
>
> Adrian Colyer wrote:
> > AspectJ lets us declare pointcuts within aspects, classes and interfaces.
> > To create 'library' pointcuts I need to be able to declare pointcuts in
> > an interface (and let users of the library program to the interface), and
> > then have implementers of the interface provide concrete implementations
> > of those pointcuts. Exploring the behaviour of AspectJ 1.1 I see that we
> > are part of the way there, but not fully. What I am about to describe is
> > partially bug and partially feature request...
> >
> > Today I can write:
> >
> > public interface Foo {
> >
> >    public pointcut bar();
> >
> > }
> >
> > This compiles happily, and I can refer to Foo.bar() in advice (it doesn't
> > match any joinpoints).
> >
> > If I write
> >
> > class C implements Foo {}
> >
> > this does not cause a compilation error (I believe it should, since C
> > does not define pointcut bar which it's interface contract says it
> > should).
> >
> > If I write
> >
> > class C implements Foo {
> >   public pointcut bar() : execution(... ...);
> > }
> >
> > this compiles happily. Writing advice against Foo.bar does not match
> > anything, writing advice against C.bar() matches the execution
> > joinpoints. The desired behaviour is that writing advice against Foo.bar
> > should match against the C definition.
> >
> > If I write
> >
> > aspect A implements Foo {}
> >
> > this does not cause a compilation error (I believe it should, since C
> > does not define pointcut bar()).
> >
> >
> > If I change the interface definition to
> >
> > public interface Foo {
> >   public abstract pointcut bar();
> > }
> >
> > then compilation of A fails with "inherited abstract pointcut Foo.bar()
> > is not made concrete in A" (good, but tells me that the pointcut is not
> > being implicitly made abstract when defined in an interface). Compilation
> > of the empty C declaration still does not produce the compilation error.
> >
> > How I think I would like this to behave is that pointcuts declared in
> > interfaces are implicitly abstract (just like method definitions in
> > interfaces). If a class or aspect declares that it implements the
> > interface without providing a concrete definition of the pointcut then
> > this is a compilation error.  Clients should be able to write advice
> > against the interface, and the advice will apply to joinpoints matching
> > any of the  concrete implementations of interface in the system (same
> > rules as for abstract / concrete aspect pairs).
> >
> > Why this is important:
> > * I  can create a standard interface that clients program to
> > * Multiple parties can implement the interface to provide concrete
> > implementations that make sense within their system. These can even be
> > binary so that implementation details are never exposed to clients.
> >
> > What do others think?
> >
> > -- Adrian
> > Adrian_Colyer@xxxxxxxxxx
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev

-- 

******************************************************************************
Arno Schmidmeier
+49/9151/90 50 30
or A@xxxxxxxxxxxxxxx
******************************************************************************
Yes, I have realized several projects with AspectJ.
Yes, I do provide consulting for AspectJ.