Hi Chris,<br>
<br>
My co-authors and I discuss just this question in two papers that I
posted recently to this list. One is to appear in the proceedings of
ESEC/FSE in the fall. The other is in review. You can find them in the
AOSD archives in the last few weeks. Among other things we discuss the
logging concern, (not tracing), problems with the notion of
obliviousness as commonly construed (i.e., "Just write the code, and we
can add the aspects later"), and a solution approach. In a nutshell, we
would suggest that you do the following:<br>
<br>
* Specify the program execution phenomena of interest -- here, perhaps, a notion of "loggable action"<br>
<br>
* Define what we call a crosscut programming interface, or XPI, that
presents these phenomena in an advisable form (In AspectJ, if that's
what you're using, you'd define an aspect module that emulates the XPI,
and this aspect would export a named PCD, with an explicit promise to
aspect clients that all and only the phenomena of interest are captured
by the PCD)<br>
<br>
* Impose a "design rule" on your coders that requires that they write
code that matches the given PCD if and only if the code implements an
occurence of the specified phenomenon of interest. One possibility for
logging -- there are surely others -- is that every loggable event is
explicitly flagged by a call to a "no-op" method with a name that
uniquely matches the given PCD and with parameters that you want to
expose to aspect clients of the given XPI. Following the rules is the
way that a programmer "implements" the XPI. In my example, this
involves adding code that wouldn't be there otherwise (yes, violating
that notion of obliviousness quoted above). In other cases, one can
implement an XPI just by following specified rules for method and
variable naming, signatures, posible structure of the stack (for
cflow), without actually adding any code that you wouldn't otherwise
need.<br>
<br>
Finally, you might want to reconsider "loggable action" as a concern.
It might be more effective to provide a number of differet crosscutting
abstract XPI's, e.g., one for "failure event," one for one particular
set of normal application-specific actions, one for another such set,
etc. You can then write one or more "logging" aspects, and possible
other aspects, too, against (i.e., that advise) the PCD's of these XPIs.<br>
<br>
What about obliviousness? Well, you developers have to be aware of and
have to "implement" the XPI's, but they needn't be aware of the aspects
that use these interfaces.<br>
<br>
This approach also has the potentially significant benefit of allowing
for parallel development of aspect and advised code. No longer do
aspect writers have to wait for the "base" developers to make their
coding decisions before the aspect developers can proceed.<br>
<br>
Kevin Sullivan<br>
University of Virginia<br>
<div><span class="gmail_quote"><br>
On 6/30/05, <b class="gmail_sendername">Chris Elgar</b> <<a href="mailto:Chris.Elgar@solnetsolutions.co.nz">Chris.Elgar@solnetsolutions.co.nz</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi<br>
<br>
I can clearly see benefits in using AOP for tracing system execution.
But my question is how to use AOP in conjunction with logging. When I
say logging I am referring to the other things developers log in a
systems execution such as exceptions and messages at well selected
points. I provide the following code example to illustrate this:<br>
<br>
Logger log = Logger.getLogger(ClassName.class);<br>
<br>
private List methodName(ArrayType[] data) {<br>
<br>
if(log.isDebugEnabled()) log.debug("ClassName.methodName - start");<br>
<br>
List list = new ArrayList();<br>
<br>
if (data.length == 0) {<br>
// no names returned<br>
log.warn("No names returned");<br>
} else {<br>
// do something<br>
}<br>
<br>
if(log.isDebugEnabled()) log.debug("ClassName.methodName - end");<br>
<br>
return list;<br>
}<br>
<br>
It is easy enough to write an aspect to handle the tracing in a very
transparent way. However, what is not clear to me is how to handle
logging such as that in the if statement. This form of logging is often
an important source of information to a developer and not including it
would no doubt make problem determination/debugging more difficult.
This type of logging is also very specific to particular points/state
of the program, so the messages do not have the same generic feel to
them that tracing has. How have other people tackled this problem? I
see two possibilities:<br>
<ol>
<li>Declare a logger within classes still. Use this for logging
information that cannot be captured within aspects.<br>
</li>
<li>Add loggers to classes using an aspect. These can be accessed
from within the class through get methods. This implies that the class
and developer must be aware of aspects. We lose obliviousness.</li>
</ol>
Both of these approaches suffer since some logging must still be
tangled with the core logic. Is this avoidable?<br>
<br>
Thanks Chris.<br>
<br>
<br>
Attention:
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or <a href="mailto:postmaster@solnetsolutions.co.nz" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">postmaster@solnetsolutions.co.nz</a> as
soon as possible. The content of this email does not necessarily
reflect the views of SolNet Solutions Ltd.
<br>
<br>__________________________________________________<br>AOSD Discuss mailing list - <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:discuss@aosd.net">discuss@aosd.net</a><br>To unsubscribe go to
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://aosd.net" target="_blank">http://aosd.net</a><br><br>Check out the <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://AOSD.net" target="_blank">
AOSD.net</a> Wiki: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://aosd.net/wiki" target="_blank">http://aosd.net/wiki</a><br><br></blockquote></div><br><br><br>-- <br>Kevin Sullivan