Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Can AOP really solve the "logging problem"? 
> John W. Cocula asked:
> Can AOP really solve the "logging problem"?

It depends on what you mean by solved.  The current version of AspectJ
can help modularize logging code quite well.  It is less good at making
logging 'transparent', in the sense of not having to adjust the main
code at all to enable logging.

> Charles Zhang said:
> 
> My experience is AspectJ as it is right now can't nicely 
> solve the logging  problem. The reason is logging often
> involves intermediate states of the program ...
> 
> The usual hack I do is to write temporary methods to expose
> the logging context. That  is bad because it requires the
> coordination of the base program. 

I'm not sure I would agree this is bad.  Very often programming with
AspectJ requires adjusting the non-aspect code to make it possible to
write clean aspects.  I think (at least) three things about that:

  (a) To the extent it makes the main code cleaner anyways, then
      it's a fine thing, although it may take some work.  The job
      of the AOP is to make the logging modular, not transparent.

  (b) If it mucks up the main code, then that's a problem.

  (c) Its an AOP research issue to develop more powerful join point
      models (join points, pointcuts and advice) so that in the
      future, it becomes more and more possible to define aspects
      without explicit refactoring of the main code.  More powerful
      property based pointcuts might make it possible to identify
      more logging join points this way.


> Echlin Harmer, Elizabeth said: 

> "Temporary or local information" sounds more like debugging than logging
> IMHO. If it truly is logging information I would take a careful look at
> the system design and perform refactoring to expose the logging context. 
>
> I have been using patterns like this for my logging: 
>   pointcut majorLogPoint( Customer c, Request r) :
>       call( * Customer.*Request( Request ) )
>       && target( c )
>       && args( r )
>       && !within( Customer );
>
>    ...

> I use similar patterns for fine, finer and finest logPoint pointcuts. 

It seems that this style falls clearly into case (a) above.  Even though
some of the main code had to be refactored to enable modular logging with
AspectJ, both the main code and the logging code benefit.

The key point again is that modular means things like localized, clear
interface, (un)pluggable etc.  Transparent means it works like magic without
having to do anything.  I think the goal of separation of concerns (SOC) is
more like modularity than transparency.

Back to the top