Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Novice Newsgroups: comp.lang.java.programmer Subject: Re: Aspect questions? Date: Sat, 25 Feb 2012 23:29:09 +0000 (UTC) Organization: Your Company Lines: 255 Message-ID: References: NNTP-Posting-Host: Dmxgbnvd+eoRDUV2lwYf7Q.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: Xnews/5.04.25 X-Antivirus-Status: Clean X-Notice: Filtered by postfilter v. 0.8.2 X-Antivirus: avast! (VPS 120225-1, 2012-02-25), Outbound message Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12340 Lew wrote in news:jibn8n$17s$1@news.albasani.net: > On 02/25/2012 02:12 PM, Novice wrote: >> Lew 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