Re: Aspect questions?
Novice wrote:
Lew wrote:
Logging is a great use case for aspects. However, there are
alternatives to lessening logging's overhead, too. You have to weigh
costs and benefits.
What are other good ways to do logging?
log4j is my favorite.
Right now, the two main programs in my current project each create their
own logger and then pass it to the classes they call in their parameters.
I don't think that's a good pattern. Which logging library are you using?
I have each class create its own logger (log4j style shown:
package eegee;
import org.apache.log4j.Logger;
import static org.apache.log4j.Logger.getLogger;
public class Foo
{
final Logger logger = getLogger(getClass());
public void foo()
{
logger.debug("");
// do the fooey stuff
try
{
// do the trying stuff
}
catch (FooException exc)
{
String msg = "trying stuff failed. "+ exc.getLocalizedMessage();
logger.error(msg, exc);
throw new IllegalStateException(msg, exc);
}
}
}
This boilerplate is what aspects aim to remove from the code and I espouse
retaining.
Either way the logger should be tied to the actual class emitting log
messages, not some common class.
The called classes write their messages to that logger. I've created a
method that does the logger creation and put it in a utility class in my
Common project so that my programs only need to execute that method
(passing in a few parameters of course) and get an appropriate logger
back. Each of the classes instantiated by the main programs gets a logger
passed among their parameters. The newly instantiated class then verifies
that the logger is not null and throws an IllegalArgumentException if it
is. Each class writes to the log when it seems appropriate. Sometimes,
that is to log an Exception. Other times, I log things that are more
diagnostic in nature. If a method isn't 100% right yet, I will log
calculations that it is doing, such as calculating the width of a column
in a JTable or whatever.
Did you reinvent the logging wheel? If so, does your logging framework feature
log levels, infinitely flexible log formats, logging to screen or (rolling)
file logs, virtual elimination of logging overhead at levels finer than
configured, automatic if slow retrieval of class and method and line where the
logging happens, XML configuration, portability, a large body of online
literature describing its use, standardization, widespread adoption, and a
body of top developers contributing to the project?
This works okay but it seems to me that it might be more elegant to put
the logging in aspects, especially the diagnostic stuff that I am using
to verify that the suspect methods are doing their jobs correctly.
What is "elegant"?
Personally I promote "useful" as the useful metric.
I'm not sure yet if all the logging code, including the creation of the
log itself, should go into aspects though. It probably makes more sense
to create the logger the way I am doing it and continue to do the actual
Not from your description of it.
writes to the logs in my existing classes when it involves Exception
handling. The diagnostic logging, though, seems like a prime candidate
for the aspects. I could write pointcuts that specify the methods that
are a little dubious and log them in as much detail as I need. Methods
that are already working to my satisfaction could be left alone with only
their Exception logging.
Logging is logging is logging, to misquote Gertrude Stein. Suddenly now you've
created two logging aspects. That's not elegant.
Logging shouldn't be added to and removed from code. That's not the purpose of
logging. Logging is to remain in the code forever.
Logging is not for the developer. That's an all-too-common misconception.
Logging is for the sysop.
Have you ever tried to suss out a production issue from the logs?
The sort of dynamic granularity you describe is built in to the logging
framework. You use levels - DEBUG for debug purposes (or FINE if you're using
java.util.logging), WARNING for warnings, ERROR (SEVERE) for errors, and so
forth.
By removing logging to AspectJ, you eliminate the flexibility, visibility and
granularity of control logging should support.
It's not just in the code you weigh. Frameworks have a deployment
cost. It's harder to deploy than to write code. Framework bloat is a
major problem in the real world. Aspects also reduce visibility into
areas, sometimes a good thing and others not.
What do you mean when you say "framework"? That term puts me in mind of
things like Spring - which I know of but have never used - but I'm not
using any formal frameworks like that and know very little about them.
I'm getting the impression that you are thinking of my work as being sort
of a homegrown framework. Maybe it is; I really don't know.
A deployment or code base that handles some part of the project under the hood
for you, and gives you a public interface for control of its behavior. In your
case I'm referring to the AspectJ framework. Logging is also a framework, one
apparently you are not using.
Use log4j or java.util.logging (or both). Those are (both) foundational and
you should learn (both of) them very early in your Java career.
Remember - logging is meant to be there in production, for benefit of sysops
and system reliability engineers. Code is not the be-all and end-all of
programming.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg