You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Christopher Lenz <cm...@gmx.de> on 2003/01/16 17:07:55 UTC
Cactus and AspectJ
Folks,
this is likely a quite controversial message, but I'd like to state my
opinion on this matter and get some feedback.
The Cactus framework is currently using AspectJ (since when?). AspectJ
is used for a LogAspect, which is responsible for logging trace-level
messages when a method is entered/exited. This looks like a good
solution, as you read about logging as one of the primary examples in
every introduction about AOP.
However, my concern that we're paying to high a "price" for a pretty
small gain. The gain is that AspectJ separates parts of the logging
aspect of Cactus from the "actual" code.
But really only *parts* of the logging aspect. If we want any logging
above the method-enter/exit traces, we call Commons-Logging directly
from the code. And often enough, that is the kind of logging that really
matters: the developer makes an informed decision that the relevant
section of code is critical enough to emit a log message.
The "price" we pay:
1 An additional runtime dependancy (aspectjrt.jar)
2 Additional build dependancies: the AspectJ compiler and the Ant
tasks, and - although currently disabled - the AspectJ javadoc. A
build-time dependancy is in some ways worse than a runtime dependancy
because it complicates the build file.
Also note that the AspectJ compiler doesn't provide good dependancy
checking (probably because it can't, it's all about cross-cutting
concerns after all), so an edit to a single source file causes a
complete recompile.
3 Obscured stack traces: the traces contain "weird" around_699()-style
methods that are confusing. Especially for a testing framework such
as Cactus, readable stack traces are pretty important IMHO.
4 The Clover-generated code coverage reports shows code that looks
different than the original code. I'm not 100% sure if this is still
true, or whether it's actually the fault of AspectJ.
Now, I'm not saying any of these disadvantages are very critical. But I
do think they by far outweigh the benefits provided by AspectJ for
Cactus. For example, if there were plans to make more use of AOP in the
code base, that would put the whole situation into a different light.
Contra?
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cactus and AspectJ
Posted by Nicholas Lesiecki <ni...@eblox.com>.
I mean to respond to this, I just haven't had the time yet. I will probably
do so sometime this week.
Cheers,
Nick
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: Thursday, January 16, 2003 9:08 AM
> To: Cactus Developers List
> Subject: Cactus and AspectJ
>
>
> Folks,
>
> this is likely a quite controversial message, but I'd like to state my
> opinion on this matter and get some feedback.
>
> The Cactus framework is currently using AspectJ (since when?). AspectJ
> is used for a LogAspect, which is responsible for logging trace-level
> messages when a method is entered/exited. This looks like a good
> solution, as you read about logging as one of the primary examples in
> every introduction about AOP.
>
> However, my concern that we're paying to high a "price" for a pretty
> small gain. The gain is that AspectJ separates parts of the logging
> aspect of Cactus from the "actual" code.
>
> But really only *parts* of the logging aspect. If we want any logging
> above the method-enter/exit traces, we call Commons-Logging directly
> from the code. And often enough, that is the kind of logging that really
> matters: the developer makes an informed decision that the relevant
> section of code is critical enough to emit a log message.
>
> The "price" we pay:
> 1 An additional runtime dependancy (aspectjrt.jar)
> 2 Additional build dependancies: the AspectJ compiler and the Ant
> tasks, and - although currently disabled - the AspectJ javadoc. A
> build-time dependancy is in some ways worse than a runtime dependancy
> because it complicates the build file.
> Also note that the AspectJ compiler doesn't provide good dependancy
> checking (probably because it can't, it's all about cross-cutting
> concerns after all), so an edit to a single source file causes a
> complete recompile.
> 3 Obscured stack traces: the traces contain "weird" around_699()-style
> methods that are confusing. Especially for a testing framework such
> as Cactus, readable stack traces are pretty important IMHO.
> 4 The Clover-generated code coverage reports shows code that looks
> different than the original code. I'm not 100% sure if this is still
> true, or whether it's actually the fault of AspectJ.
>
> Now, I'm not saying any of these disadvantages are very critical. But I
> do think they by far outweigh the benefits provided by AspectJ for
> Cactus. For example, if there were plans to make more use of AOP in the
> code base, that would put the whole situation into a different light.
>
> Contra?
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cactus and AspectJ
Posted by Nicholas Lesiecki <ni...@eblox.com>.
+1 Sounds like a perfect use for AspectJ.
Cheers,
Nick
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Saturday, February 22, 2003 5:52 AM
> To: 'Cactus Developers List'
> Subject: RE: Cactus and AspectJ
>
>
>
>
> > -----Original Message-----
> > From: Nicholas Lesiecki [mailto:nick@eblox.com]
> > Sent: 06 February 2003 01:14
> > To: Cactus Developers List
> > Subject: RE: Cactus and AspectJ
> >
> > In response to Vincent:
> > <<<
> > 1/ as a development tool for the cactus framework itself, i.e. find
> > other usages in addition to logging. I'm open to suggestion. BTW, this
> > is what I find the hardest in AOP: finding usages for it (it may have
> to
> > do with my mindset working in "traditional" ways!)
> > >>>
> >
> > I agree with Vincent--more of Cactus' code could use AspectJ. Again,
> > however, finding the right spots to do it can be difficult. I think
> this
> > is
> > the most compelling use case until we are more familiar with AOP.
>
> I think I may have a use case for more AOP. I'd like to have your
> opinion though. Lots of our Cactus classes need to be handed both a
> Logger and a Configuration objects. ATM, the Configuration object is
> usually passed in the constructors and the Logger is retrieved
> statically.
>
> One option to improve this is of course to use the Avalon Framework and
> a ComponentManager such as ECM or Merlin/Fortress/etc. However, I'm
> loathe to do this as it means adding new jar dependencies to the Cactus
> project for no additional user-visible features. That said, we're
> starting to have some nice Cactus front-ends which hides much of this...
>
> Anyway, one simple solution is to add a Loggable and Configurable
> interfaces (with getter and setters for Log and Configuration objects).
> Then we can have a very simple Aspect (which acts as a very basic
> ComponentManager in Avalon parlance) which simply traps initialization
> (i.e. constructor) of new Cactus classes and if they implement Loggable
> pass them a Log object and if they implement Configurable pass them a
> Configuration object.
>
> Ideas? Comments?
>
> Thanks
> -Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Cactus and AspectJ
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Nicholas Lesiecki [mailto:nick@eblox.com]
> Sent: 06 February 2003 01:14
> To: Cactus Developers List
> Subject: RE: Cactus and AspectJ
>
> In response to Vincent:
> <<<
> 1/ as a development tool for the cactus framework itself, i.e. find
> other usages in addition to logging. I'm open to suggestion. BTW, this
> is what I find the hardest in AOP: finding usages for it (it may have
to
> do with my mindset working in "traditional" ways!)
> >>>
>
> I agree with Vincent--more of Cactus' code could use AspectJ. Again,
> however, finding the right spots to do it can be difficult. I think
this
> is
> the most compelling use case until we are more familiar with AOP.
I think I may have a use case for more AOP. I'd like to have your
opinion though. Lots of our Cactus classes need to be handed both a
Logger and a Configuration objects. ATM, the Configuration object is
usually passed in the constructors and the Logger is retrieved
statically.
One option to improve this is of course to use the Avalon Framework and
a ComponentManager such as ECM or Merlin/Fortress/etc. However, I'm
loathe to do this as it means adding new jar dependencies to the Cactus
project for no additional user-visible features. That said, we're
starting to have some nice Cactus front-ends which hides much of this...
Anyway, one simple solution is to add a Loggable and Configurable
interfaces (with getter and setters for Log and Configuration objects).
Then we can have a very simple Aspect (which acts as a very basic
ComponentManager in Avalon parlance) which simply traps initialization
(i.e. constructor) of new Cactus classes and if they implement Loggable
pass them a Log object and if they implement Configurable pass them a
Configuration object.
Ideas? Comments?
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Cactus and AspectJ
Posted by Nicholas Lesiecki <ni...@eblox.com>.
In response to Vincent:
<<<
1/ as a development tool for the cactus framework itself, i.e. find
other usages in addition to logging. I'm open to suggestion. BTW, this
is what I find the hardest in AOP: finding usages for it (it may have to
do with my mindset working in "traditional" ways!)
>>>
I agree with Vincent--more of Cactus' code could use AspectJ. Again,
however, finding the right spots to do it can be difficult. I think this is
the most compelling use case until we are more familiar with AOP.
> * Nick Lesiecki and I are quite enthusiastic about AOP and more
> specifically using AOP for unit testing. The idea is to provide the same
> testing flexibility as Mock Objects but in a much much simpler way. We
> wanted (and still want) to add some AOP testing functionality to Cactus
> in Cactus 2.0. Nick has had to work on some other stuff but I know we is
> still keen to continue this. You can search the developer archives for
> AOP or AspectJ.
Yes, I still mean to continue this. However, I probably need to open the
discussion up about what would make a valuable addition to Cactus.
Unfortunately, MockObjects are simpler in most cases (though AspectJ trumps
them when you wish to use Mock EJBs or Mock static method calls). What
AspectJ can do is neatly swap in a mock object when necessary. However, is
this useful to Cactus as an in-container testing framework? I don't know.
Anyway, that's probably a separate discussion.
(You can see some of my investigation and conclusions in:
http://www-106.ibm.com/developerworks/java/library/j-aspectj2/?loc=j)
In response to Chris:
<<<
However, my concern that we're paying to high a "price" for a pretty
small gain. The gain is that AspectJ separates parts of the logging
aspect of Cactus from the "actual" code.
>>>
I agree that it's not a total logging solution, but I really would rather
not see all of the removed log calls re-added to the source.
I respond to the drawbacks:
<<<
2 Additional build dependancies: the AspectJ compiler and the Ant
tasks, and - although currently disabled - the AspectJ javadoc. A
build-time dependancy is in some ways worse than a runtime dependancy
because it complicates the build file.
Also note that the AspectJ compiler doesn't provide good dependancy
checking (probably because it can't, it's all about cross-cutting
concerns after all), so an edit to a single source file causes a
complete recompile.
>>>
This is probably the best point, though AspectJ 1.1 does better dependency
checking (or will if it ever emerges from beta).
<<<
3 Obscured stack traces: the traces contain "weird" around_699()-style
methods that are confusing. Especially for a testing framework such
as Cactus, readable stack traces are pretty important IMHO.
>>>
For us yes, they need to be readable. However, they *are* readable if you
know a little about AspectJ. For our users, they don't really need to be, as
most of the time they don't need to analyze the Cactus stack trace.
<<<
4 The Clover-generated code coverage reports shows code that looks
different than the original code. I'm not 100% sure if this is still
true, or whether it's actually the fault of AspectJ.
>>>
Yes, it's AspectJ's fault. I agree that we should probably run only one
source/class munging tool on the cactus source. However, I'd say Clover is
the one to go.
Cheers,
Nick
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Friday, January 31, 2003 2:14 PM
> To: 'Cactus Developers List'
> Subject: RE: Cactus and AspectJ
>
>
> Hi Chris,
>
> It is indeed controversial! :-)
>
> To make it short, yes, I would like to add more pointcuts. Ok, a bit
> more of history:
>
> * Some time ago, I had introduced another use of AOP in Cactus. It was a
> configuration checker that was checking if the user configuration of
> Cactus was ok and it was reporting nice and informative errors if it
> were not. I can't remember why I removed it (maybe because I have done
> it in a "better" way using standard exceptions). I can't really recall
>
> * Nick Lesiecki and I are quite enthusiastic about AOP and more
> specifically using AOP for unit testing. The idea is to provide the same
> testing flexibility as Mock Objects but in a much much simpler way. We
> wanted (and still want) to add some AOP testing functionality to Cactus
> in Cactus 2.0. Nick has had to work on some other stuff but I know we is
> still keen to continue this. You can search the developer archives for
> AOP or AspectJ.
>
> There were issues with the static weaving thing issue which prevented us
> doing nifty things in Cactus. I was eagerly waiting for AspectJ 1.x in
> order to get weaving of bytecode. It is there now but I haven't found
> the time to investigate it yet.
>
> I would really like to continue using AOP in Cactus and research it
> more. There are several axis of research:
>
> 1/ as a development tool for the cactus framework itself, i.e. find
> other usages in addition to logging. I'm open to suggestion. BTW, this
> is what I find the hardest in AOP: finding usages for it (it may have to
> do with my mindset working in "traditional" ways!)
>
> 2/ as ways to simplify Cactus, i.e. could it be used instead of the
> redirectors to intercept calls inside the container? That would
> eliminate the need to configure the cactus redirectors in web.xml...
>
> 3/ as solution to improve In-container testing by providing easy to use
> mock replacement (Cactus 2.0)
>
> Ideas? Comments?
>
> Thanks
> -Vincent
>
> PS: I would hate to have to put entry and exit log statements in every
> public method... :-)
>
> > -----Original Message-----
> > From: Christopher Lenz [mailto:cmlenz@gmx.de]
> > Sent: 16 January 2003 17:08
> > To: Cactus Developers List
> > Subject: Cactus and AspectJ
> >
> > Folks,
> >
> > this is likely a quite controversial message, but I'd like to state my
> > opinion on this matter and get some feedback.
> >
> > The Cactus framework is currently using AspectJ (since when?). AspectJ
> > is used for a LogAspect, which is responsible for logging trace-level
> > messages when a method is entered/exited. This looks like a good
> > solution, as you read about logging as one of the primary examples in
> > every introduction about AOP.
> >
> > However, my concern that we're paying to high a "price" for a pretty
> > small gain. The gain is that AspectJ separates parts of the logging
> > aspect of Cactus from the "actual" code.
> >
> > But really only *parts* of the logging aspect. If we want any logging
> > above the method-enter/exit traces, we call Commons-Logging directly
> > from the code. And often enough, that is the kind of logging that
> really
> > matters: the developer makes an informed decision that the relevant
> > section of code is critical enough to emit a log message.
> >
> > The "price" we pay:
> > 1 An additional runtime dependancy (aspectjrt.jar)
> > 2 Additional build dependancies: the AspectJ compiler and the Ant
> > tasks, and - although currently disabled - the AspectJ javadoc. A
> > build-time dependancy is in some ways worse than a runtime
> dependancy
> > because it complicates the build file.
> > Also note that the AspectJ compiler doesn't provide good
> dependancy
> > checking (probably because it can't, it's all about cross-cutting
> > concerns after all), so an edit to a single source file causes a
> > complete recompile.
> > 3 Obscured stack traces: the traces contain "weird"
> around_699()-style
> > methods that are confusing. Especially for a testing framework
> such
> > as Cactus, readable stack traces are pretty important IMHO.
> > 4 The Clover-generated code coverage reports shows code that looks
> > different than the original code. I'm not 100% sure if this is
> still
> > true, or whether it's actually the fault of AspectJ.
> >
> > Now, I'm not saying any of these disadvantages are very critical. But
> I
> > do think they by far outweigh the benefits provided by AspectJ for
> > Cactus. For example, if there were plans to make more use of AOP in
> the
> > code base, that would put the whole situation into a different light.
> >
> > Contra?
> >
> > --
> > Christopher Lenz
> > /=/ cmlenz at gmx.de
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:cactus-dev-
> > unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:cactus-dev-
> > help@jakarta.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Cactus and AspectJ
Posted by Vincent Massol <vm...@octo.com>.
Hi Chris,
It is indeed controversial! :-)
To make it short, yes, I would like to add more pointcuts. Ok, a bit
more of history:
* Some time ago, I had introduced another use of AOP in Cactus. It was a
configuration checker that was checking if the user configuration of
Cactus was ok and it was reporting nice and informative errors if it
were not. I can't remember why I removed it (maybe because I have done
it in a "better" way using standard exceptions). I can't really recall
* Nick Lesiecki and I are quite enthusiastic about AOP and more
specifically using AOP for unit testing. The idea is to provide the same
testing flexibility as Mock Objects but in a much much simpler way. We
wanted (and still want) to add some AOP testing functionality to Cactus
in Cactus 2.0. Nick has had to work on some other stuff but I know we is
still keen to continue this. You can search the developer archives for
AOP or AspectJ.
There were issues with the static weaving thing issue which prevented us
doing nifty things in Cactus. I was eagerly waiting for AspectJ 1.x in
order to get weaving of bytecode. It is there now but I haven't found
the time to investigate it yet.
I would really like to continue using AOP in Cactus and research it
more. There are several axis of research:
1/ as a development tool for the cactus framework itself, i.e. find
other usages in addition to logging. I'm open to suggestion. BTW, this
is what I find the hardest in AOP: finding usages for it (it may have to
do with my mindset working in "traditional" ways!)
2/ as ways to simplify Cactus, i.e. could it be used instead of the
redirectors to intercept calls inside the container? That would
eliminate the need to configure the cactus redirectors in web.xml...
3/ as solution to improve In-container testing by providing easy to use
mock replacement (Cactus 2.0)
Ideas? Comments?
Thanks
-Vincent
PS: I would hate to have to put entry and exit log statements in every
public method... :-)
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 16 January 2003 17:08
> To: Cactus Developers List
> Subject: Cactus and AspectJ
>
> Folks,
>
> this is likely a quite controversial message, but I'd like to state my
> opinion on this matter and get some feedback.
>
> The Cactus framework is currently using AspectJ (since when?). AspectJ
> is used for a LogAspect, which is responsible for logging trace-level
> messages when a method is entered/exited. This looks like a good
> solution, as you read about logging as one of the primary examples in
> every introduction about AOP.
>
> However, my concern that we're paying to high a "price" for a pretty
> small gain. The gain is that AspectJ separates parts of the logging
> aspect of Cactus from the "actual" code.
>
> But really only *parts* of the logging aspect. If we want any logging
> above the method-enter/exit traces, we call Commons-Logging directly
> from the code. And often enough, that is the kind of logging that
really
> matters: the developer makes an informed decision that the relevant
> section of code is critical enough to emit a log message.
>
> The "price" we pay:
> 1 An additional runtime dependancy (aspectjrt.jar)
> 2 Additional build dependancies: the AspectJ compiler and the Ant
> tasks, and - although currently disabled - the AspectJ javadoc. A
> build-time dependancy is in some ways worse than a runtime
dependancy
> because it complicates the build file.
> Also note that the AspectJ compiler doesn't provide good
dependancy
> checking (probably because it can't, it's all about cross-cutting
> concerns after all), so an edit to a single source file causes a
> complete recompile.
> 3 Obscured stack traces: the traces contain "weird"
around_699()-style
> methods that are confusing. Especially for a testing framework
such
> as Cactus, readable stack traces are pretty important IMHO.
> 4 The Clover-generated code coverage reports shows code that looks
> different than the original code. I'm not 100% sure if this is
still
> true, or whether it's actually the fault of AspectJ.
>
> Now, I'm not saying any of these disadvantages are very critical. But
I
> do think they by far outweigh the benefits provided by AspectJ for
> Cactus. For example, if there were plans to make more use of AOP in
the
> code base, that would put the whole situation into a different light.
>
> Contra?
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-dev-
> help@jakarta.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org