[aosd-discuss] Handling logging and tracing concerns

[Kevin Sullivan]

Hi Chris,

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:

* Specify the program execution phenomena of interest -- here, perhaps, a 
notion of "loggable action"

* 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)

* 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.

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.

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.

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.

Kevin Sullivan
University of Virginia

On 6/30/05, Chris Elgar <Chris.Elgar at solnetsolutions.co.nz> wrote:
> 
> Hi
> 
> 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:
> 
> Logger log = Logger.getLogger(ClassName.class);
> 
> private List methodName(ArrayType[] data) {
> 
> if(log.isDebugEnabled()) log.debug("ClassName.methodName - start");
> 
> List list = new ArrayList();
> 
> if (data.length == 0) {
> // no names returned
> log.warn("No names returned");
> } else {
> // do something
> }
> 
> if(log.isDebugEnabled()) log.debug("ClassName.methodName - end");
> 
> return list;
> }
> 
> 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:
> 
>    1. Declare a logger within classes still. Use this for logging 
>    information that cannot be captured within aspects.
>     2. 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. 
> 
> Both of these approaches suffer since some logging must still be tangled 
> with the core logic. Is this avoidable?
> 
> Thanks Chris.
> 
> 
> 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 
> postmaster at solnetsolutions.co.nz as soon as possible. The content of this 
> email does not necessarily reflect the views of SolNet Solutions Ltd. 
> 
> __________________________________________________
> AOSD Discuss mailing list - discuss at aosd.net
> To unsubscribe go to http://aosd.net
> 
> Check out the AOSD.net <http://AOSD.net> Wiki: http://aosd.net/wiki
> 
> 


-- 
Kevin Sullivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/discuss_aosd.net/attachments/20050630/87b36238/attachment.htm