Re: [ajdt-dev] Load-Time weaving questions

[Marius Danciu <mdanciusv@xxxxxxxxx>]

Matthew, I really apreaciate your detailed feedback on
this. Indeed it sounds more consistent to do this
using pointcuts and leave aspects associated with
classloader constant. 

The fact is that I asked those question because I
needed to understand better AspectJ load-time weaving.
An thanks to you I do now. I'm working on a bytecode
manipulation tool that among other things may be used
to allow transparent transaction demarcation on
specific pluggable components. I know, I know this can
be done with AspectJ or Spring has great support for
this via Spring AOP. 

Thank you,
Marius

--- Matthew Webster <matthew_webster@xxxxxxxxxx>
wrote:

> 
> 
> 
> 
> Marius,
> 
> Modifying the set of aspects defined to a
> classloader is dangerous in the
> same way that modifying its classpath (other than
> appending) would be
> dangerous: either it has no effect because classes
> have already been loaded
> or it causes unpredictable behaviour because 2
> classes loaded at different
> times are affected by different versions of a third
> class. The design of
> LTW ensured your application behaves the same as if
> you had compiled and
> woven the classes and aspects ahead of time. This is
> very important as the
> choice of phase when weaving takes place (compile,
> post-compile load-time)
> should be orthogonal to the purpose of the aspects
> used. One clarification:
> in AspectJ 5 aspects cannot be added to
> WeavingURLClassloader.
> 
> The best way to determine which aspects affect which
> classes is to use
> pointcuts: this way the classes and aspects together
> describe the intended
> behaviour of your application. This can be refined
> at load-time using the
> include/exclude clauses of aop.xml. If you need to
> control i.e.
> enable/disable a feature applied through an aspect
> the best approach is to
> use whatever configuration capability that feature
> has. You also might like
> to look at Adrian's blog entry
>
http://www.aspectprogrammer.org/blogs/adrian/2005/03/perinstance_asp.html.
> Try to think of LTW as part of a larger picture
> rather than just a neat way
> to change the behaviour of your application.
> 
> 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/
> 
> Marius Danciu <mdanciusv@xxxxxxxxx>@eclipse.org on
> 30/08/2005 21:06:33
> 
> Please respond to AspectJ Development Tools
> developer discussions
>        <ajdt-dev@xxxxxxxxxxx>
> 
> Sent by:    ajdt-dev-bounces@xxxxxxxxxxx
> 
> 
> To:    Wes Isberg <wes@xxxxxxxxxxxxxx>, AspectJ
> Development Tools developer
>        discussions <ajdt-dev@xxxxxxxxxxx>
> cc:
> Subject:    Re: [ajdt-dev] Load-Time weaving
> questions
> 
> 
> 
> Thanks a bunch for this.
> 
> Marius
> --- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> 
> > > why aspects need to remain
> > > constant?
> >
> > If the aspect doesn't apply to an entire
> namespace,
> > then
> > many pointcuts and advice won't work as expected.
> > For example:
> >
> >   before() : call(void setX(Integer i)) { ... }
> >
> > would not work on *all* calls, only on the classes
> > woven.
> > Effectively, the decision to apply aspects is a
> > bounds on
> > the AspectJ language, which can make it very
> > difficult to
> > reason about and understand.  There are specific
> > situations
> > where that's intended and could be
> well-understood;
> > for
> > those situations, a pointcut can and should be
> used.
> >
> >
> > {warning: long-winded elaboration...}
> >
> > Historically, this was an engineering requirement
> as
> > well
> > as a semantic one; even though it's
> circumventable,
> > defining aspects first and applying them to the
> > namespace has the correct semantics and is more
> > usable.
> >
> > In the AspectJ 1.0 days, we used to do
> "callee-side
> > call
> > join points", where the call join point could be
> > implemented
> > in the target class.  This required some
> > coordination between
> > the caller and the callee, as well as
> whole-program
> > analysis
> > by the compiler.  In that situation, weaving some
> > classes but
> > not others would break the pointcut.  The weaver
> has
> > since
> > been redesigned to support incremental
> compilation,
> > so each
> > class can be separately woven.  (However, there
> may
> > still
> > be situations where the engineering won't work. 
> For
> > example,
> > our implementation of declaring members on
> > interfaces works
> > on all top-level classes implementing the
> interface;
> > it would
> > fail when some implementing classes were not
> woven.)
> >
> > You can, of course, get the partial-weaving effect
> > by
> > segregating classes into jars, one woven and one
> > not,
> > during a build.  And the WeavingURLClassLoader I
> > think
> > permits you to add aspects; that means you can
> weave
> > with
> > one set of aspects and then with a superset,
> > effectively
> > omitting the classes loaded before the superset
> from
> > being woven with the added aspects.  So if you can
> > try
> > it and it sometimes work, why not?
> >
> > Semantically, the idea is to consolidate all
> > crosscutting
> > specifications and make them susceptible to both
> > human
> > and machine processing - to put them all in {an}
> > aspect{s}.
> > With build configuration files and LTW support in
> > aop.xml,
> > the consolidation isn't perfect, but still is
> > intended to
> > apply to a namespace in its entirety.
> >
> > The interesting questions come with binary
> aspects,
> > where the use-model is for one person to write the
> > aspect
> > and another person applies it using a concrete
> > subaspect.
> > Assuming the pointcut should specify the target
> > classes
> >
> >   protected pointcut p() : within(com.foo.bar..*);
> >
> > That could be saying the same thing as "weave only
> > these
> > classes with this aspect."  But since there's a
> way
> > to
> > say that with AspectJ, and since weaving some but
> > not other
> > classes in a namespace can make things hard to
> > understand,
> > we adopted the guidance about weaving namespaces
> as
> > a
> > whole with the same set of aspects.  (You lose
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com