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