[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] SCM & aspectj
|
I think that the "one weave rule" and the new "supporting multiple weaves"
should be considered properties of ajc, and not AspectJ. A corollary of
that is that the semantics of multiple weaves should be the same as they
would be for a single big weave.
Otherwise the semantics is going to start getting pretty squirrely. With
a rule like the above, you could apply Observer more than once, which makes
sense. But you couldn't do something like try to find join points that
occurred within a class only because a previous weave had copied them there.
> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of
> Lesiecki Nicholas
> Sent: Saturday, July 12, 2003 12:10 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] SCM & aspectj
>
>
> In Response to Ron's comment:
>
> <<<
> One of
> the big challenges I see is in defining behavior if you apply the same
> aspect (even an abstract aspect) more than once. Presumably that would
> still
> be an error.
> >>>
>
> Perhaps I'm misunderstanding you, but this doesn't make sense to me.
> Presumably I could wish to apply an Observer-Pattern aspect
> to the same
> class twice, during two different build steps. For instance
> if an Employee
> changes status I may want both a GUI view and a remote
> resource notified.
>
> Does this present a logical problem?
>
> I would wholeheartedly support an RFE removing the one-weave
> rule. As it
> is, it could make it very difficult to reuse pre-woven jars
> with your own
> aspects. For instance, the Cactus project uses aspects
> internally. If I
> wanted to apply some aspects of my own to solve a testing problem, I
> couldn't do it. This promotes a tension between those who wish to use
> aspects in building reusable components and frameworks, and
> those who wish
> to use them to build applications.
>
> Cheers,
> Nick
>
> --- Eric.D.Friedman@xxxxxxxxxxxxxx wrote:
> > Ron,
> >
> > Thanks very much for your thoughtful reply. For the
> record, one other
> > problem that would arise out of multiple weaving passes is
> that of aspect
> > dominance. Suppose that a library was woven with certain
> aspects and
> > then
> > rewoven with others. There'd be no way to elegantly handle
> the question
> > of
> > execution order, since the library aspects might
> encapsulate behavior
> > that
> > would be distorted by a different execution order, but the
> build process
> > for
> > those aspects wouldn't be capable of asserting their
> dominance (or lack
> > thereof) w.r.t to application level aspects. A simple
> example of this is
> > the old timing + logging case -- should timing aspects
> include time spent
> > logging? Suppose that you decide to answer that question by making
> > logging
> > dominate timing. OK, but what if you've modularized your
> builds such
> > that
> > logging doesn't know that timing exists and so can't dominate it? A
> > nasty
> > problem, IMHO.
> >
> > In any event, thanks for your practical advice; it's appreciated.
> >
> > Eric
> >
> > -----Original Message-----
> > From: Ron Bodkin [mailto:rbodkin@xxxxxxxxxxx]
> > Sent: Friday, July 11, 2003 1:53 PM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] SCM & aspectj
> >
> >
> > Eric,
> >
> > This sounds like a compelling example of why ajc should
> allow weaving
> > more
> > than once. Allowing one aspect to layer on top of another one
> > independently
> > seems to be completely in synch with the spirit of AOP. I'd
> definitely
> > support an RFE for 1.2 to allow this.
> >
> > We should investigate how much work it would take to
> support this. One of
> > the big challenges I see is in defining behavior if you
> apply the same
> > aspect (even an abstract aspect) more than once. Presumably
> that would
> > still
> > be an error. Given that, I wonder how hard this would be to
> support. One
> > problem I can think of is naming the AspectJ-introduced members and
> > attributes in the bytecode: perhaps that could be based on
> the specific
> > aspect or class in question?
> >
> > For now, I would have the build script for the reusable
> libraries create
> > multiple versions of the jars, which weave all useful
> combinations of
> > aspects into the libraries. This lets applications just use
> jars; they
> > pick
> > among preconfigured versions. It seems to me to be the best
> of the bad
> > choices available.
> >
> > Ron
> >
> > Ron Bodkin
> > Chief Technology Officer
> > New Aspects of Security
> > m: (415) 509-2895
> >
> > > ------------Original Message-------------
> > > From: Eric.D.Friedman@xxxxxxxxxxxxxx
> > > To: aspectj-users@xxxxxxxxxxx
> > > Date: Fri, Jul-11-2003 10:40 AM
> > > Subject: [aspectj-users] SCM & aspectj
> > >
> > > I have a somewhat lengthy question about software configuration
> > management
> > > (SCM) practices and aspectj. I'd be grateful for any
> insight you folks
> > can
> > > offer.
> > >
> > > On a large project, it's quite common to break the code
> base up into
> > > separate libraries that roughly equate to the "separation
> of concerns"
> > in
> > > the design. So, for example, a large web application
> might contain
> > several
> > > jar files of "application" code, in addition to the usual
> servlets and
> > other
> > > GUI related code. The goal of this practice would be to enable
> > developers
> > > to work on those underlying libraries independently of the web
> > application
> > > context. This is a good practice because it increases
> the likelihood
> > that
> > > the underlying libraries can be reused in other (non-web)
> contexts as
> > well.
> > > As a matter of developer efficiency, this approach also allows for
> > "build
> > > avoidance" -- if you're working on the GUI, you don't need to keep
> > > recompiling the underlying libraries, and vice versa.
> > >
> > > It's also quite common, in my experience, for those underlying
> > libraries
> > to
> > > have their own unit test suites to cover the behavior of
> the library in
> > a
> > > manner that doesn't assume usage in the web context.
> Finally, it's
> > common
> > > to want to "certify" a version of the library in its own right,
> > > independently of the application(s) in which it's deployed. It's
> > therefore
> > > important the library be buildable in a consistent and
> repeatable way
> > no
> > > matter which application ends up using it.
> > >
> > > Consider the following example: a project contains 3
> distinct layers,
> > > packaged as jars, and organized in separate builds for the reasons
> > described
> > > above:
> > > base messaging layer -- a distributed messaging framework
> of some kind,
> > say
> > > SOAP [layer 1]
> > > business logic layer -- components that represent
> business entities and
> > that
> > > rely on the base messaging layer to get things done [layer 2]
> > > presentation layer -- web stuff, say struts actions --
> implemented in
> > terms
> > > of the business logic layer [layer 3a]
> > >
> > > Let's further suppose that the two first two layers are
> reused in a
> > second
> > > application, one with a different presentation layer (a
> conventional
> > GUI,
> > or
> > > command line interface) [layer 3b].
> > >
> > > So, there are two applications, but they share two
> underlying libraries
> > in
> > > common. Application A = layers {1,2,3a} ; Application B
> = layers {1,
> > 2,
> > 3b}
> > >
> > > Enter AspectJ. As you're aware, it is not possible to
> weave the same
> > > bytecode more than once in AspectJ. What's the "best"
> way to manage
> > aspects
> > > that cut across layers? Assume that you are using
> aspects to implement
> > some
> > > fundamental, er, aspect of the application, not merely bolting on
> > logging,
> > > tracing, or timing after the thought. How do you deal
> with cases in
> > which
> > a
> > > higher layer (3a or 3b) wants to introduce advice of an
> > application-specific
> > > nature into the shared libraries' classes, which may
> already be woven
> > with
> > > aspects of their own?
> > >
> > > One answer is obviously to pull all aspects up to the
> top-level build
> > (the
> > > one that rolls up the different layers into application A
> or B). But
> > this
> > > doesn't let you use aspects in the lower layers as more than an
> > > afterthought. That is, you couldn't implement
> fundamental behavior of
> > a
> > > lower layer in an aspect and expect that layer's unit
> tests to run or
> > even
> > > compile.
> > >
> > > Another incomplete answer would be to spread aspects
> across the layers,
> > but
> > > then you have to be extremely careful to avoid the one-weave
> > restriction.
> > > It's not hard to conjure up real applications for which
> this would not
> > work.
> > >
> > > the only approach I know of that would work in all cases
> is to always
> > > compile everything, but then you lose the build avoidance
> benefits, and
> > you
> > > increase the risk of library and application code being
> co-mingled.
> > Also,
> > > you lose the ability to test/certify a library without
> regard to the
> > > application that uses it.
> > >
> > > Many thanks in advance for your thoughts on this one,
> > > Eric Friedman
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> > >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
