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