Re: Aspect questions?
Lew <noone@lewscanon.com> wrote in news:jibn8n$17s$1@news.albasani.net:
On 02/25/2012 02:12 PM, Novice wrote:
Lew<noone@lewscanon.com> wrote in
news:jibf3u$ee9$1@news.albasani.net:
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'm using Java Logging. Does that answer your question or are you
asking something else?
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.
My code is not terribly different than that.
Actually, what you do is different and some of that difference is
terrible.
Why aren't you logging the exceptions?
Because this is the code that creates the logger. If it fails to create
the logger, where would you like me to log the exception?
And what you are doing here is radically different from what I
proposed, hardly at all similar in any respect. I don't understand why
you think it's similar.
Okay, maybe it's completely different then. I thought it was the same
spirit.
Here's the actual code minus the Javadoc comment:
================================================================
public static Logger configureLogger(String className, String
logFilePath, String logFileName, Locale locale, Formatter formatter,
Level loggingLevel) {
My goodness, don't use TABs! Especially not in Usenet posts!
Sorry.
This use of a separate logger factory that takes over what the logging
framework already does is, well, curious.
String METHOD_NAME = "configureLogger()"; //$NON-NLS-1$
You don't need this, and if you did it should be 'final' and named
according to the Java coding conventions.
I thought final was irrelevant in a method and only made a difference for
instance variables?
You're right about the case of the name. That should be methodName for a
method variable....
/* Ensure that the mandatory parameters have all been specified.
*/ if (className == null) {
throw new IllegalArgumentException("The name of the class
must
be provided."); //$NON-NLS-1$
You didn't log this!
Where would you like me to log this?
And those "$NON-NLS-1$" comments are highly distracting.
Sorry, I should have stripped them and the tabs out of the code first.
}
if (logFilePath == null) {
throw new IllegalArgumentException("The log file path must
be
provided."); //$NON-NLS-1$
}
if (logFileName == null) {
throw new IllegalArgumentException("The log file name must
be
provided."); //$NON-NLS-1$
}
if (locale == null) {
throw new IllegalArgumentException("The locale must be
provided."); //$NON-NLS-1$
}
/* Create the logger. */
Logger logger = Logger.getLogger(className);
/* Create path identified by logFilePath if it does not exist.
*/ File path = new File(logFilePath);
Really?
I can't go on. It's too painful.
Why? Telling me it's awful without saying why doesn't teach me anything.
I put that in a utility class in my Common project. Then any program
that wants a logger just executes this one method passing the
appropriate parameters.
But, splutter, but, ... that's what the existing 'Logger.getLogger()'
method does!
You're doing everything by hand that the framework does for you!
So I just execute Logger.getLogger() and a logger will be magically
created that is exactly where I want it to be with exactly the file name
I want to ensure that it is in the right format, XML in my case and with
exactly the right logging level and handlers? I thought I had to do SOME
of the work to ensure I got what I wanted.
I realize that I could have each class create its own logger and log
but
Huh?
No!
would seem to guarantee a proliferation of logs that would be a pain
to find. It seems reasonable to me that if I have a bunch of
programs,
No, no, no, no.
You don't create multiple log files, one per class. Where did you get
that notion?
Huh? You seem to be contradicting yourself. Are you saying I should
create one logging file per class or not? And why have a separate logging
file for each class? Isn't it more logical to have all the messages that
come from one program, say Foo, appear in the same log? Isn't the poor
Sysop going to be excessively busy if he has to check a separate log for
each and every one of the - hundreds? thousands? - of classes in the
system? Wouldn't it be more logical to group logs on the basis of which
application is invoking the class? Therefore, if method
getCurrentWeekdayName had problems while executing program Foo, the Foo
log would contain the information? Wouldn't the person running Foo be the
one that's notifying the SysOp that something screwy just happened while
running Foo? Then the name of the application would be a huge head start
in finding the problem: just look in the Foo log and all will be
revealed. Or at least enough to get started.
You set up the logging in the configuration file. Done. Simple.
What configuration file? I'm not sure what you mean. First, I'm not sure
what you mean by a configuration file. Second, are you saying that all
applications will normally have a configuration file? I don't remember
coming across those in the Java Tutorial, for example, or even seeing
them mentioned in this newsgroup.
If this is some routine thing that professional developers do, great. I
obviously need to know about it. Can you point me to a tutorial or
whatever that will explain what they are and how to create them?
You are re-inventing the logging wheel. You said,
Goodness no! I am using the Java Logging classes to do my logging.
Sorry if that wasn't clear.
but you aren't using it correctly. What you are doing is defeating the
built-in features and reinventing everything. Don't do that.
That was not my intention. I'm off to look at the logging classes again
and see how I can avoid reinventing the wheel. I'm really not seeing why
you say that yet. I'm using the standard Java Logging classes. I've
tweaked the properties file that governs logging a little bit to get the
effect that I wanted and I created my own variant on the XMLFormatter
that is only very slightly different. Aside from that, I'm using the
vanilla logging classes. I'm not sure how that constitutes reinventing
the framework. But, as I said, I'm going to review the logging classes
now and see if I'm overcomplicating the creation of the logger as you
say. Perhaps I am....
And when I said you should know both ju.logging and log4j, somehow you
inferred that to mean that you should use both in the same program.
Such leaps you make! Settle back and stick with inferences that
actually follow from what I say.
Well, here's the exact quote:
"Use log4j or java.util.logging (OR BOTH)". [emphasis added]
I don't think it's completely unreasonable to take that as a suggestion
to use both within a single program. Which is why I asked you about it.
Hey, I'm just trying to learn and I'm prepared to hear things that
surprise me. There might be some case to be made for logging redundantly
to two separate loggers that I hadn't considered. It seems farfetched to
me but it seemed like what you were saying.
Did you ever hear that old saying, attributed to various ancient
personages?
?He who knows not and knows not he knows not: he is a fool - shun him. He
who knows not and knows he knows not: he is simple - teach him. He who
knows and knows not he knows: he is asleep - wake him. He who knows and
knows he knows: he is wise - follow him.?
In that context, I consider myself "simple": I know that there are a
bunch of things I don't know. I'm looking at the people in this newsgroup
as being in the 'wise' category and am trying to learn from you.
As I've said, I'm a one man Java shop in a town that doesn't seem to do
much Java. I don't work in a professional Java shop so I have no
professional Java code to look at or peers to learn from. So I'm
floundering. That's why this newsgroup is important to me. I _AM_ trying
to get better at this....
--
Novice