• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Use of JDK1.4 logging

 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to use JDK1.4 logging in my assignment.
To avoid changing the C:\JDK142\jre\lib\logging.properties file, I have written 2 simple classes.
1. MyFormatter class extends Formatter = overrides the only method format() to format the log message(s) approriately with timestamp, classname, methodname etc...
2. MyLogger class contains 2 Logger objects as members(1 for client and 1 for server) and initializes the loggers to use FileHandler objects and the MyFormatter class.

My test application is logging fine to the log files BSClient.log and BSServer.log in the current directory, but everytime I run my program, 2 empty files are getting created BSClient.log.lck and BSServer.log.lck in the same directory.
1. I do not know why these 2 temp files are created as part of the JDK1.4 logging framework.Is there a way to suppress the creation of these 2 files?
2. I was also expecting a close() method for the Logger class but couldn't find any in the API. Does the logging framework handle the closing of the log files also?
3. Lastly, is the use of JDK1.4 logging recommended for this assignment?
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vishwa,


1. I do not know why these 2 temp files are created as part of the JDK1.4 logging framework.Is there a way to suppress the creation of these 2 files?


You don't need to care about those files. There are produced by the logging API to handle possible access conflicts to your log files. *But* I wouldn't advice you to upload your assignment set up to generate log files. Doing so would just be taking the risk of some I/O error due to your logging code.


2. I was also expecting a close() method for the Logger class but couldn't find any in the API. Does the logging framework handle the closing of the log files also?


AFAIK, there is no explicit close() method indeed.


3. Lastly, is the use of JDK1.4 logging recommended for this assignment?


Logging is a good practice in any real-world application and the logging API is a standard J2SE API. So why not to use it? So yes, I think it's recommended (at the minimum as a help for you to debug your app), though not mandatory at all. But I repeat it: make sure you haven't any FileHandler set up by default.
Regards,
Phil.
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Phil,
I have always found the other types of logging quite useful for debugging.

Currently there are a couple of default handlers set up for my JDK(C:\JDK142\jre\lib\logging.properties).

I do not intend to use any of them for the assignment, as I am not expecting the examiner to fiddle around the logging.properties
file.
I have a class which initializes my logger object (clientLogger).

I think the above piece of code does not depend on the default handlers setup in the logging.properties file as I have disabled the parent handlers for my logger object.(before that it was writing to the console as well!).I guess Max's project depends on the configuration of loggers in the logging.properties file but I prefer do it without depending on this file.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vishwa,
I feel I've much to reply to you, but unfortunately I cannot do it today. Sorry about that. I'll come back in this thread as soon as possible (at worst during next weekend ).
Regards,
Phil.
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vishwa,
I did almost identical to you - except I just made 1 handler for all modes. This works fine even running on the same machine. The logger itself just increases the number test.log.1 for each time the application request a new logger.
I also have put the logger to log in current working directory. I also use this concept for writing my properties file (suncertify.properties). Of course there can be IO problems when trying to write to current directory but I think it is resonable to assume that it is ok - how do we else handle property files and logging? It is not possible to use setup - at least not in my application - cause if it does not find a property file it will create one.
My approach is to test it on a couple of machines (including a Unix box) and see if it works. Then I will document that the user must have rwx priveledges to the current working directory. I hope this is sufficient to pass SCDJ - but I will certainly follow this stream
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No worries Phil,
I found one of ur posts on logging, yeah......the recent big one....that would be sufficient food for me for the weekend.
Martin,
I am using 2 loggers with 2 diff. handlers. 1 is used by the client-side classes and the other by the server-side classes, for all modes. OK, It will generate the log files in the current directory, but your idea of using logger class to generate suncertify.properties file seems a bit innovative to me. How are you reading the properties file?

If the application does not find a suncertify.properties file, creating one with the default properties seems to be a good idea.....Some of the ranchers here had mentioned that they had submitted their assignment without testing it on a Unix box, so I don't think I would worry much about it.
(The only issue that comes to my mind is the FileSeperator constant, if we use getSystemProperty() to get the relevant FileSeperator for the OS, I think we might be alright)
 
Martin Rea
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Vishwa,
Reading my respons again I can see my formulation was quite unclear.
I'm not using the logger API for property file - just Properties.
What I meant was, that I am writing properties to current directory. Actually it is required that I do that - or at least changes made by the user is persisted in a property file residing in current directory.
If this is a requirement I cannot see that there should be any problems writing another file (the log-file) to current directory.
- but again I could be wrong...
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Martin,
No worries. Possibly, I didn't interpret it correctly.....I think expecting SunCertify.properties to be in the current directory is reasonable. If the user tries to run the program from a different directory, the program would expect the properties to be present in that directory. I think we will have to document this clearly in the choices.txt file.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vishwa,

No worries Phil,
I found one of ur posts on logging, yeah......the recent big one....that would be sufficient food for me for the weekend.


I guess it's this one.

I am using 2 loggers


It's good practice to have one static logger per class, named with the fully qualified name of the class
(package included). Here is an example:

That gives you to the maximum of control on levels (whole application, packages, group of sub-packages and classes) that you can easily set up in an external logging file. Very handy during development (once a whole package is debugged you can increase it's level for all the classes it contains with only one line in your config file) but also in production (if you suspect a given class, you may easily decrease its level the same way).
Regards,
Phil.
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's right. Cheers Phil.
 
reply
    Bookmark Topic Watch Topic
  • New Topic