JDK Logging question

[Jim Janssens]

I want to use logging in my assignment. In the first place because I'm used to write logging. Its good practise (rather then using std out's) and its a lot better for tracing problems. Normally I use commons logging as api and as implementation log4j. But I know that jdk 1.4 has its own logging api.
So I think it would be 'safer' to use the jdk api...

First because the assignment says you should not creat things that are allready offered by the JDK. And second, because it mentions somehwhere that no additional libraries are necesairy and tirth, that you should write all the code yourself. So I think that are enough reasons to use the jdk logging.

Now, I noticed that it works a bit different then log4j. For intance, the configuration file (logger properties) is stored in: "%java_home%\jre\lib" .

But, I want to add different loggers per package, and I also want to control them on a package base. So I can put the log from RMI server to error and the log for the database to debug.

I tried to place the configuration file in my classpath, but it still uses the one in the jdk directory...
Then, I found out somewhere that you can change the configuration file by setting a jvm property... Is this a good idea ? Is it allowed to do this , and also , is it allowed to ship the property file in my project ? (in the root for example) ? ..

[Nikolay Elenkov]

Hi,

One other thing you might want to consider is configuring your logger programmatically. Something in the lines of:

 
Logger logger = Logger.getLogger("suncertify");
FileHandler fh = new FileHandler("server.log");
fh.setFormatter(new SimpleFormatter());
logger.addHandler(fh);
logger.setLevel(Level.WARNING);
 

That way you don't have to deal with property files, but it would require a bit more work to make your logger globally accessible to all classes.

HTH

[Jim Janssens]

ic...

Personnaly I find it BAD practise to do this. You should never ever configure a logger programatically !
Anyway, keeping in mind that offering a property file may go against the rules, I'm thinking of following that advice.

What I'm planning to do;

- Do it like you say, configure it programmatically.
- Make this configuration dynamically by adding it to the gui configuration pane. So that you can choose per package (yeah, its hard coded then...) which level of logging you want, wit the default on "SEVERE"

However, when the server is started in standalone mode, you will not have such posibility to configure the logger;..

[Nikolay Elenkov]

Personnaly I find it BAD practise to do this. You should never ever configure a logger programatically !

I agree. I like the commons/log4j way better and usually use it, but no this time

Anyways, something I just tried and seems to work: put your logging configuration in suncertify.properties and call LogManager.readConfiguration() when you start your program.

FileInputStream fis = new FileInputStream("suncertify.properties");
LogManager.getLogManager().readConfiguration(fis);

[peter wooster]

For this assignment, I'm using the 1.4 logging support and leaving the configuration exactly where Sun put it. This way the examiners will be able to set it in a way they are familiar with.

[Jim Janssens]

Yeah, but then they have to add all the loggers seperatly. For example, if they only want to see the logging of your database, the have to add a line saying this..

Also, about adding the logger properties to the suncertify properties file, isn't that a bad idea ? I think its better to let it build the initial configuration from the logger.properties located in java_home and then programmatically manipulate it according to the configuration file...

Btw: is there a way to manipulate SimpleFormatter so that you can define some kind of pattern ? like [time][class][level][msg] . Now its on 2 lines:
[time] [class]
[level] [message]

I know I can write a custom formatter, but if you can achieve this with the original formatter it would be better....

[Zafer Abu saeed]

"Also, about adding the logger properties to the suncertify properties file, isn't that a bad idea ? "

I think not.

It is expected to configure the logging framework using your own properties file. Think why there is such a method:
LoggerManager.readConfiguration(InputStream) ?

If the APIs creator intended to re-configure the logging based on the default properties file, then there is no need to provide an InputStream. Keep in mind that this is a re-configuration, meaning that the logging has been configured before, and the properties file location is known.

This is the javadoc for the readConfiguration method which may help:
Reinitialize the logging properties and reread the logging configuration from the given stream, which should be in java.util.Properties format.
[ November 30, 2004: Message edited by: Zafer Abu saeed ]

[Jim Janssens]

Yes. But thats not what I meant.
It is good to have a seperate property file --no doubt.
But you are going to mix your gui configuration and logger configuration in one property file. So in other words, your gui configuration *can* influence your logger configuration when you choose keys badly...

Therefore I think its better to

1 let it configure by default using the properties located @ jdk dir
2 change the configuration dynamically , hard coded
3 safe an extract of the configuration to the gui property file

for 3 you could save something like this:

LogOutput= file, console
DBLogger = debug
GUILogger= error
RMILogger = info

[Andy Zhu]

I am not sure if I want to log at client such as mentioned guilog. At least, I didn't see the reason to convince myself to do so. I only log in the data.java. Though I do have a question about log config, but I don't have my code at hand.

I don't know whether we can simply use the default log config. Did some one do this and no marks down for it? I wish because I won't raise my question again.

[Andy Zhu]

OK, I am now be able to bring my question about logging. The same as mentioned, do we allow to use the default logging properties? Does Sun have any explicit policy of this issue?

Andrew: do you have some answer to us?