NX: Is logging really this easy???

[Terry Martinson]

I just tried out the 1.4 logging framework. I didn't really do anything fancy. I'm hoping I'm not missing something, because it just seems like there is not much to it.
Here's what I did:
1. added instance variable to a class in package "packageName"
private Logger log = Logger.getLogger("packageName");
2. modified exception type System.out.printlns in that class to say
log.severe("bad stuff happened here")
3. modified any info-type System.out.printlns in that class to say
log.info("cool thing happened here")
4. modified the logging properties in jre/lib to use both Console and File handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
My questions:
1. Can I assume that the grader will have the appropriate logging properties file for whatever they want to see?
2. Would there be any reason my log.info or log.severe statements could fail in the grader's environment.

Thanks.
TJ

[Ken Krebs]

TJ,
Make sure that when you are logging non-serious information, i.e. INFO, that you make sure to test if the current level requires it to be logged so that you don't execute any expensive String operations when they aren't needed. You could get a deduct if you don't do that.

[Mark Spritzler]

I don't recall logging being a requirement in the assignment. I would suggest removing the logging code before you submit. But test your app again right after you remove the code to make sure you didn't get any extra characters removed that would create a bug.
You can't assume that the marker will have anything on their computer except the JRE.
Mark

[Terry Martinson]

Boy, I'm confused now.
I keep going back and forth on whether to put in the "fancy" java logging framework, or just leave a few informational System.out.printlns in there to print info to the console (like Network server started, Client application started, database file closed, etc.). I was thinking before that most folks on the forum were suggesting we use the fancier logging.
I would be interested in some other opinions on whether or not its ok to just leave System.out.printlns writing necessary info to the console.
TJ

[Ken Krebs]

Logging is not a requirement but I cannot agree with Mark about removing it before submission.

1. Almost any real application should have some kind of logging, even a small one.
2. It can be helpful to the tester if you supply them with a good logging.properties file to put in the working directory assuming of course that that's the one you use in your code.
My submission scored well (389/400) and my certificate bears a date only 2 days subsequent to my taking the essay exam. I am convinced, though I cannot prove it, that the logging suppport I put in was an aid to achieving these results.

[George Marinkovich]

Logging was very important to me. I would have never finished without it (or rather I would have thought I was finished way before I was actually finished ). I turned off console logging but left my file logging in place since I thought it would be useful for the grader. I am also loathe to remove stuff from working code (especially something as pervasive as logging). There are no performance requirements in my assignment so I was willing to take the performance hit.
I did not use a logging.properties file. It was simpler for me just to hard-code the logging setup stuff. logging.properties is the proper way to do this, but I just didn't want to spend any more time on it and was worried about a potential deployment problem. For the same reason I didn't even package a suncertify.properties file with my project (the runme.jar creates one the first time it's run).
I don't hear anyone recommending against logging. Mark's point is that the logging should be removed and the executable retested before you submit. I won't argue against that advice since it seems sensible to me. I'll only point out that I didn't remove the logging myself and I guess I'm not terribly worried about not having done so.
Hope this helps,
George

[Philippe Maquet]

Hi Terry,
I agree with Mark when he recalls that logging is not a requirement for this assignment. But I would suggest you to keep your logging code in your submission.
Logging is useful for debugging, but it's useful in production as well. The needs will be different (default level, levels per package/class, etc.), but the logging code itself doesn't need any change to aim those different needs (debugging at development stage / application monitoring at production stage). Keeping your logging code just proves that you really understood the benefits of the 1.4 logging API. It really cannot hurt.

My questions:
1. Can I assume that the grader will have the appropriate logging properties file for whatever they want to see?
2. Would there be any reason my log.info or log.severe statements could fail in the grader's environment.

I wouldn't count on the grader's logging environment.
You can check whether the System property "java.util.logging.config.file" was set through the java command line, and if it's not the case, hardcode your internal logging environment (example : level INFO or WARNING for all classes and the console as the only handler). If you use them, you'll see that logging config files are really useful during debugging, because they help you in setting the individual classes logging levels that suit your current debugging needs, whithout even touching your logging code.
That technique is explained here.
Best,
Phil.

[Mark Spritzler]

Actually my statements were just that it is not a requirement.
And knowing that having something in there that is not a requirement can have you lose points, but will never ever ever gain you any points.
So leaving it in or not is your decision. But you are taking a chance of losing points leaving it in.
Mark

[Philippe Maquet]

Hi Mark,

And knowing that having something in there that is not a requirement can have you lose points, but will never ever ever gain you any points.

You're right at 100%.

So leaving it in or not is your decision. But you are taking a chance of losing points leaving it in.

Yes, but only if your logging is not implemented correctly, but would it be the case if you used logging extensively for debugging purposes ?
And as you write yourself in your first post in this thread, removing logging at final stage means - by definition - touching your code base, which brings the need for new tests of everything. But this time, without the help of the logging ! Isn't it risky too ?
Best regards,
Phil.

[Mark Spritzler]

"But this time, without the help of the logging ! Isn't it risky too ?"
Yes, that is why I re-phrased my reply to state that my only concern for users is leaving in bad code that could lose them points. And that the app would have to be retested if you removed all that code.
Mark

[Jay Bromley]

Hello Ken,
You say to test the level of non-essential log messages to avoid costly String operations. Did you mean something like:

  
Logger log = Logger.getLogger("org.foo.bar");
...
if (log.getLevel().intValue() >= Level.INFO.intValue()) {
    log.info(/* some costly String operation */);
}
...

Regards,
jb

[Billy Tsai]

i didnt use any logging

[Bharat Ruparel]

Hello All,
Now to make this really confusing, here is my 2 cents. I wasn't using logging originally, but put that in at Andrew's urging, and thanked him everyday for it. It was invaluable in debugging the threading/locking code. I got similarly worried about leaving logging code or commenting it out. I searched the forum and found that Max advised leaving it in, but logging to console or standard error since that is the safest way to keep the logging in the application. I did leave it in.
Regards.
Bharat

[Ken Krebs]

Jay,

You say to test the level of non-essential log messages to avoid costly String operations. Did you mean something like:

Here is a sample.

        if (logger.isLoggable(Level.INFO)) {
            logger.info(
                "book invoked: recNo="
                    + recNo
                    + " customer="
                    + customer
                    + " for "
                    + Thread.currentThread());
        }

[Max Habibi]

My opinion is that logging is a great idea, so long as you don't log to a file(just to avoid any File IO issues): log to the console to your heart's content. It's a good way to provide feedback on exceptions, etc.
All best,
M

[Ken Krebs]

Max,

My opinion is that logging is a great idea, so long as you don't log to a file(just to avoid any File IO issues)

I'm confused. The Javadoc says that Handlers will call an associated ErrorManager if there is a problem rather than throwing some sort of exception. So what's your problem with logging to a file ?

[Max Habibi]

I don't generally recommend logging to a file(in the SCJD assignment) because that's just one more thing that might go wrong: for example, your file might simply fail to open. In a real application, my opinion would be different. But here, IMO, it's an unjustified risk. Logging to the console, OTOH, is risk free. So in spirit, I agree with Mark, but in implementation, I'm inclined to Andrew's point of view.
Also, I wouldn't worry about the cost of the String operations. The J2SE logging features already check the current level of logging, and I'd let that mechanism handle your logging needs: it knows if you need to log an INFO versus a more/less serious error. We could discuss the relative cost of two checks(your own and the automatic one) versus the potentially unnecessary String operations, of course, but performance/memory isn't an issue in this application, and either way, we're not talking about a lot of difference here. I would probably use the built-in J2SE features here, and not try to improve on them, even if I could achieve a slight efficiency gain by doing so.

All best,
M
[ January 21, 2004: Message edited by: Max Habibi ]

[Ken Krebs]

Max,
I agree with you about the effiency thing not really being an issue here, though it is something you should be aware of for coding a real app. My concern is more along the lines that if you don't do it, you might get a markdown by some smartass tester

[Max Habibi]

While such is possible, it doesn't seem like justifiable grading criteria: I doubt the graders would mark you off for using a standard feature in a standard way.
All best,
M