[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ajdt-dev] Load-Time weaving questions
|
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
> mainly where
> the aspect writer didn't anticipate that the aspect
> shouldn't
> apply to certain classes, and you're stuck with the
> aspect.)
>
> Wes
>
> P.S. -
> You say
> > > that should be ok using it
> > > programatically just to load certain classes at
> > > runtime, right?
>
> With hierarchical classloaders you can carve off an
> namespace
> which has a constant set of aspects, but only
> applies to
> specified classes. (All other classes would be
> loaded by the
> parent loader, and the parent loader should not be
> loading
> the specified classes.) The difference here is that
> anything
> that sees those specified classes is also in that
> namespace.
> However, that's a hard way to try associating
> specific aspects
> with specific classes.
>
> > ------------Original Message------------
> > From: Marius Danciu <mdanciusv@xxxxxxxxx>
> > To: "AspectJ Development Tools developer
> discussions" <ajdt-dev@xxxxxxxxxxx>
> > Date: Tue, Aug-30-2005 6:55 AM
> > Subject: Re: [ajdt-dev] Load-Time weaving
> questions
> >
> > Thank you Matthew.
> >
> > You're saying
> > "This mechanisms ensures that all classes loaded
> by a
> > classloader are woven with the same constant set
> of
> > aspects (very important)."
> >
> > This means that aspects provided to classloader
> weaves
> > class A and then when loading class B you can not
> > change the set of spects to weave class B? ...
> even if
> > aspects are already loaded by ExtensionClassLoader
> > (for example) ? ... why aspects need to remain
> > constant?
> >
> > Regards,
> > Marius
> >
> > --- Matthew Webster <matthew_webster@xxxxxxxxxx>
> > wrote:
> >
> > >
> > >
> > >
> > >
> > > Marius,
> > >
> > > The interface you need is
> > > org.aspectj.weaver.loadtime.Aj in the "loadtime"
> > > project (no examples yet). You cannot replace
> > > aop.xml yet but I can imagine
> > > supplying Aj with a "provider" interface
> allowing
> > > you to programmatically
> > > determine the set of aspects to be woven. This
> > > mechanisms ensures that all
> > > classes loaded by a classloader are woven with
> the
> > > same constant set of
> > > aspects (very important).
> > >
> > > 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
> > > 19/08/2005 14:05:02
> > >
> > > Please respond to AspectJ Development Tools
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
