Forums Register Login
Hello Ranchers,

I'd like to share my logging approach with you and see if it is any good.

I decided to use java logging utility not only as a handy debugging tool, but also as a part of my final application. So, once the app is ready, all errors and warnings should be logged into a "suncertify.log" file in a simple text format.

To support this I created a class in my db package with a static method getLogger(). This method takes a name of a logger as a parameter, and then dynamically changes the default settings (formatting, log file name, level etc) and returns the resulting logger. If an IO exception occurs, it returns a default logger as per logging.properties.

My initial thought was to go with a property file to be able change logger settings without having to recompile the code. But:
1. we are allowed only one property file
2. we can't ask examinator to change any files manually
3. our own logging.properties file can be only provided at run time, which would contradict requirements of starting the application

In my class I created a couple of constants - level, log file name, etc. which may be changed when the app is deployed. This way these properties may be relatively easily changed, but the code would still require to be recompiled.

What do you think about this direction for logging? I'd love to hear your thoughts!
[ February 13, 2006: Message edited by: Svitlana Dukhovna ]

i successfully passed last year, so maybe it helps if i describe what i did:

i used java.util.logging, of course, what else. i used a strict logging policy for each log-comment i wrote in the code. so i took care that .info() is really only used for importat informative messages, while .severe() would only indicate real serious situtations and so on.

even though i used a .properties file during development, i was not allowed to submit one to sun, more or less the same as you describe. but i decided (and documented) to leave all logging in the code, which means that nothing below .info() gets logged (to standard-out).

should a motivated tester want to change this, he can put a properties file in the class path at any time...

i think i wrote a line about it this in my general considerations and got no deduction (say: full points) in this fields.

hope it help,
Hi Jan,

Thanks for your response. I am on a similar path as you in terms of leaving log statements in the code after deployment, and a strict policy for using log levels.

I don't like the default settings of the log file though. I know I can modify them as I like while developing, but once I submit, the examinator will see log statements on the console and the log file will be XML named java0. I want the application to output no statements on the console, but create a text log file in a current directory. I think it will give it a more professional flavor. To make this standard, I came up with what I described in my first post.

There aree 4 things "hardcoded" in my code for logging: Log level, file name, setting file handler to simple text and turning off/on of the console handler. What are the odds that someone might want to change these things when the application is deployed? If they suddenly want a log file in XML format, would not it mean some changes in the application as well? If standard info worning and error log messages are not enough, does not it mean there are bigger problems with the code and it needs to be changed, recompiled and redeployed as well?

What do you think about it? Thanks again for your help!
hi Svitlana,

even though i understand your motivation i'd say that you are working beyond the scope of the assignment. and this brings you into trouble, because you still have to meet the requirements - no config files, no vm-arguments...

...which in some sort of chain-reaction leeds you to ugly design - hard-coded config settings.

from my judgement of the situation, i'd rather skip anything hardcoded. lets put it like this: if you have no way to set configuration variables, the cost of professionalizing your logging overweight the benefits.

that's my opinion, but hey, you asked :-)

many greetings from berlin,
Thanks Jan!

After thinking over your approach, I decided to skip "hardcoding". You are right - it is not worth it, no matter how much I dislike the default settings.

Best wishes to you from Detroit!

Originally posted by Svitlana Dukhovna:
I know I can modify them as I like while developing, but once I submit, the examinator will see log statements on the console and the log file will be XML named java0.

I just had a look at my default logging.properties file, it says

By default we only configure a ConsoleHandler, which will only
show messages at the INFO and above levels.

I know there is an XMLFormatter mentioned in the default logging.properties file but it is not used ... by default
Or am I missing something

Ronald Wouters
yes. the default log configuration we are refering to is not set through any (default) logging.properties files, but through some hard wired logic in the logging factory...

Yep. Sorry about confusion guys.
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database

This thread has been viewed 924 times.

All times above are in ranch (not your local) time.
The current ranch time is
Jan 21, 2019 05:35:13.