[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
