Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] SCM & aspectj

I agree with this principle. It would be very beneficial for ajc to support applying abstract aspects like Observer more than once. By contrast, applying the same concrete aspect more than once is not sensible (if one supported it at all, it would have the same effect as weaving once).

However, I suspect it will be difficult to implement weaving of the same abstract aspect multiple times. Hopefully I'm wrong.

Ron

Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895

> ------------Original Message-------------
> From: "Gregor Kiczales" <gregor@xxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>
> Date: Sat, Jul-12-2003 2:26 PM
> Subject: 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
> > 
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> 


Back to the top