RE: [aspectj-users] SCM & aspectj

[Eric.D.Friedman@xxxxxxxxxxxxxx]

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