SCJP 1.4, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, IBM Certified Solution Developer -WebSphere Studio V5.0
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
During development, I use 3 different logging config files which are taken into account or not depending on the system property value "java.util.logging.config.file".
If my server is started like this :
code:
----------------------------------------------------------------------------
java -cp . -Djava.util.logging.config.file=c:\scjd\serverlog.properties suncertify.Run server
----------------------------------------------------------------------------
my serverlog.properties config file will be used,
while with the config file omitted like here :
The problem here is that my directions say "When you submit your assignment, each part (client and server) must be executable using a command of this exact form: java -jar <path_and_filename> [<mode>]
Your programs must not require use of command line arguments other than the single mode flag, which must be supported. Your programs must not require use of command line property specifications."
You may want to check yours.
Also, I dont know how we can assume any directory to place the logs other
than the current working directory because we are not guaranteed where they
will run our jar file. Unless you create sometype of logging file
on the fly in you code in the current working directory.
How will the grader choose to use your config files.
And the config files
shipped with your application will be located where ?
So you are saying, for example, if your packages are all in directory
"code" you stick the properties file in "code" and then jar it up.
So your code looks for your properties file using the current working
directory + "code" ?
Am I correct
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
Originally posted by Philippe Maquet:
Within the jar file, I can store my sample logging config files in any place, as far as I document it. It can even be some badly named "MyStuff" directory. If the grader - because he's in a good mood - decides to play with them, he may put them in any place he likes (even in "c:\temp").
If the grader - he's still in a good mood - decides to use them, he will use the -D system property described above, pointing to the place where he put the config file.
My code doesn't need to look at that place. It just checks if a config file is in use (see a few posts above). If it's the case, my code does nothing (I let the logging API self-configurating with the help of the config file). If it's not the case, I set a global logging level as explained above.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Originally posted by Akash Singh:
Hi Bill, Jim and Phil.
I have few questions on Logger. I would appreciate your response.
Originally posted by Akash Singh:
1. In [the] example code [above] for chained exception. Would you like to log at each point where exception is thrown , or only high level exception .
Originally posted by Akash Singh:
2. Which formatter (SimpleFormatter or XMLFormatter) is appropriate
to use ?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Jim:
I figure the logging is for me, not for the grader. I'd be perfectly happy if the grader doesn't look at it at all, since it's not a requirement. I just don't want it to get in the grader's way.
Jim:
But it's not something the user needs to know about, so I'm not spending a lot of time in the user manual explaining how to configure logging.
1. In following example code for chained exception. Would you like to log
at each point where exception is thrown , or only high level exception .
I agree with your reasoning.
However I would tend to have a value in the properties file (default to turned off) rather than having a command line option. Same logic applies: the examiner is not required to manually edit the file, but the option is there.
My preference of properties file over command line argument is that it is easier to get a user to turn logging on remotely if needed - tell them to edit the properties file using any text editor, and change a value from FALSE to TRUE. Simple. Try telling them to change a command line option over the phone! Especially with the users who only know that they "Click on the Start button, go to Programs, go to..." - they may not have permission to change anything in the standard application menus, and even if they do, they may not know how to do it.
I would not create a log file by default, unless it was automatically overwritten each time - too much danger of the customer being unaware of it and 6 months later they are out of hard drive space and cursing the developer (when they track down the issue).
I would not create a log file by default, unless it was automatically overwritten each time - too much danger of the customer being unaware of it and 6 months later they are out of hard drive space and cursing the developer (when they track down the issue).
"I'm not back." - Bill Harding, Twister
[Phil]: But once you get it, you get "for free" an additional application feature (point 2 above). Without any additional effort, you offer the application a light but useful monitoring tool.
[Jim]: This can be beneficial, but it's not exactly "for free" if I have to document it really carefully the way I do the other end-user features. You're right that people like server admins could find this useful though, so I guess I will mention it in the server section of the user guide. But I don't plan on describing the file syntax in detail, for example. I'll give a couple typical examples and refer them to Sun's documentation for details. My point is that it was an optional feature in the first place, and the only people who should be interested in it are people who can be expected to have a more tecnical background and be able to think for themselves to some extent. By letting things be specified in a logging.properties file rather than set up by the program, we make the system more flexible and configurable for those who wish to use the logging - but I don't want to do a lot of extra documentation because of this. It's an advanced user feature, as far as I'm concerned.
[Phil]: Exceptions should be logged at all levels, but maybe not at the same Logger.level, depending on the exception type.
[Jim]: Ewww. I dislike having a bunch of redundant logging code, and redundant messages in the log file. A single stack trace should have most all the info I need.
,
public void throwing(String sourceClass,
String sourceMethod,
Throwable thrown)
Log throwing an exception.
This is a convenience method to log that a method is terminating by throwing an exception. The logging is done using the FINER level.
If the logger is currently enabled for the given message level then the given arguments are stored in a LogRecord which is forwarded to all registered output handlers. The LogRecord's message is set to "THROW".
My rule of thumb in most cases is to try to log an exception exactly once, at whatever level I have decided to catch a given exception and not rethrow it. If I'm just going to rethrow, or wrap the expression in a new and different expression and then re-throw, I know that the expression will still be logged later when it's eventually caught.
My main thread and event handlers all have high-level catch blocks which log any previously uncaught Throwables.
"I'm not back." - Bill Harding, Twister
I'm still skeptical about catching and logging in mid-level methods (...) I think that as long as the initial throw is logged, you have enough to go on, as you can see that there's a throw but no catch; from there you look at the stack trace and check the source for the methods that handled the exception.
Andrew I would not create a log file by default, unless it was automatically overwritten each time
Bill This is what I am doing. But it is cleared after each run. Also during the running of the program if specific exceptions occur the user
is given a message to view the logs or call the help desk!!!![]()
Do you see this as a problem?
Jim Ewww. I dislike having a bunch of redundant logging code, and redundant messages in the log file.
Jim A single stack trace should have most all the info I need.
Jim Now there are cases where a mig-level method ...
Phil As a low-level class writer (the class, not you ! - still my english problem ...
), you cannot make any assumption on how the exceptions you throw will he handled by the client classes or yours. Maybe you will write them yourself, maybe a junior programmer will write part of them, or even your customer development team. How can you make sure that all your low-level exceptions will be properly logged in all catch blocks ?
Jim My main thread and event handlers all have high-level catch blocks which log any previously uncaught Throwables.
Jim many FINEST messages end up wasting machine cycles even when they're not yielding any messages.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Oh, there is one other sorta-exception where I do endorse catching an exception, logging it, and then retrowing it. That's in a networked server using RMI. You want to make sure there's a good long on your server for any exception that's thrown from the server, as well as a log entry on the client. So I have logging in my RemoteDBImpl class, which is basically where the highest-level of methods of the server are located. So those methods catch and log exceptions before passing them on to clients.
"I'm not back." - Bill Harding, Twister