[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] SCM & aspectj
|
I think there's more than an annoyance factor involved. AspectJ supports weaving against bytecode to allow a project can control behavior even for code they didn't write. As more and more of this code is itself built using aspects, the single weave restriction becomes more painful by forcing one back to having to have source.
Supporting multi-pass weaving would also help the build process. It would allow taking an already built base component, weaving it with your application's specific aspects, then running application-specific tests against it. This is cleaner than having to inline the build process for creating the initial jar for any consumer.
That being said, I think the only way that ajc will be able to move beyond the single pass weaving implementation is for someone to carefully analyze how to implement multi-pass weaving. Maybe there is already research on this topic? If not, it would be a great paper to see (probably after there's a paper on how ajc 1.1 weaving works).
Finally, when I said weaving an abstract aspect, I meant meaning weaving a concrete aspect that extends the same abstract aspect. My point is that the abstract aspect has an impact on the code, and this impact has to happen only once. E.g., you can't introduce count twice if you weave two aspects that extend
public abstract aspect TransactionAspect {
public interface Transactional {}
public int Transactional.count = 0;
...
Ron
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
> ------------Original Message-------------
> From: Wes Isberg <wes@xxxxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Sun, Jul-13-2003 11:25 AM
> Subject: Re: [aspectj-users] SCM & aspectj
>
> Ron Bodkin wrote:
> > ... I suspect it will be difficult to implement weaving
> > of the same abstract aspect multiple times.
>
> Abstract aspects are not woven -- only concrete aspects are.
>
> FWIW, I think the weave-once rule should be with us for a long
> time, because it avoids a ton of difficult problems with
> implementing the "single big weave" semantics Gregor described.
> Even knowing whether you understood all the difficult problems
> is itself a hard problem.
>
> It *is* annoying to rebuild a system, but more troubling,
> any libraries should be retested if they are to be woven
> with application aspects, at least until we prove what aspects
> are non-interfering. Aspects are no different from any
> other code in this respect, and we can't assume we're not
> breaking the libraries until we can verify as much with
> analysis or testing.
>
> So my response to Eric's original concern would be to
> understand more carefully what kind of testing needs to be
> done for what kinds of aspects, and to automate the analysis
> required to typify the aspects if not also the testing
> itself. The burden of rebuilding the system is annoying
> to developers accustomed to fast build cycles, but small
> relative to the potential burden of retesting. This
> testing should be reduced to what's really required by
> the particular aspects, rather than what's potentially
> required by more integrated aspects, for it to be
> manageable. (Understanding these interactions
> might be a starting point for understanding multi-weave
> implementations.)
>
> As Eric suggested, SCM steps reflect a division of
> responsibility for code. Library or system test developers
> might not test for a fault introduced by the misapplication
> of an application aspect they didn't know about to library
> code. The developer applying aspects system-wide has
> to take responsibility for the quality of the aspect and
> the code it affects. That probably means at least running
> both unit and system tests for the library and the
> application, and considering what other testing is
> required.
>
> Wes
>
> Ron Bodkin wrote:
> > 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
> >>
> >
> > _______________________________________________
> > 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
>
