Re: [aspectj-users] SCM & aspectj

["Ron Bodkin" <rbodkin@xxxxxxxxxxx>]

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
>