NX: which logging file?

[Simon Ingram]

Hi folks,
I am generating logging for my application using the standard logging.properties config file. I expected this to be in:
c:\j2sdk1.4.1_03\jre\lib
but after some initial confusion, I discovered another logging.properties in:
c:\Program Files\Java\j2re1.4.1_03\lib
this is definitely the one that is picking up the console messages. Does anyone know what governs the choice of which default file handles the logging? I am not reassigning the logging file using the system properties option on the java command.
thanks
Simon

[Ken Krebs]

Simon,
The LogManager Javadoc says:

By default, the LogManager reads its initial configuration from a properties file "lib/logging.properties" in the JRE directory.

[Simon Ingram]

Exactly Ken, the first option in my post. But no changes that I making to the loging properties file in the jre/lib location have any effect on the console messages, but when I do the same thing on the logging.properties file at the second location i.e. the "wrong one", bingo! up they come! I have tried all the usual mthings, like renaming the file first in one location then in the another and trying messages at different Levels, everything confirms that my system is picking the wrong file! I just can't explain it.
regards,
Simon

[Terry Martinson]

Simon -
I have the same setup as you, where I have 2 versions of the logging file. One in c:\jdkxxxx\jre\lib, and also the c:\program files\java\etc.
It is picking up my changes to the c:\jdkxxxx\jre\lib, which is what I expected. I can't figure out why yours won't pick them up.
See this thread. The stuff I say in that thread is really all I have done to get logging working.
Good luck.
TJ

[Ken Krebs]

Simon,
The 2nd one IS the "right one" !! for the jre that's actually beimg executed.
That is, you installed a 2nd JRE separately from the JDK.
Where does your JAVA_HOME environment variable point to ?

[Terry Martinson]

Simon -
FYI - my JAVA_HOME points to c:\j2sdk1.4.2_01\bin
Also, JAVA_HOME is the first thing in my PATH.
TJ

[Ken Krebs]

BTW, I took a different strategy towards logging. I did not modify the JRE's logging.properties at all.
When my app initializes, it looks in the current working directory for logging.properties.
If it isn't there, I programmatically initialize logging to use just a FileHandler with level set to WARNING so I can capture a record of problems for use by the B&S sys admin.
If it is there, I use it instead. In addition to the FileHandler, it also provides a ConsoleHandler. These are for use by me or the SUN tester and provide finer levels of detail. I advise the tester, in choices.txt of its existence but it has to be manually copied to the working directory to use it.
I also supplied a simple log formatter to make the appearance more readable for both methods.
[ January 16, 2004: Message edited by: Ken Krebs ]

[George Marinkovich]

Hi Ken,
If I had it to do over again (and I sincerely hope that won't be the case ) I would have done something similar to what you did. I would have had my executable use a local logging.properties file and if it was not present I would have had my executable create one based on hard-coded defaults. Instead I omitted using the logging.properties and went straight to the hard-coded logging setup. Now that I think about it I can't believe I didn't do it this way. It's really bad when you consider that I coded the suncertify.properties file the same way I should have coded the logging.properties file. The only thing I can say in my defense is that at that point of working on the project I really didn't want to spend another minute on the thing. It's a minor point perhaps, but I regret I didn't go the extra step of making the logging configurable.
-George

[Simon Ingram]

Hi Terry and Ken,
I have followed exactly the same procedure outlined by you Terry. My JAVA_HOME environment variable is c:\j2sdk1.4.1_03\bin and my Path variable ends in ;%JAVA_HOME%;. which is simply following the set up suggested by Max in his book. By the way, what do the % signs mean in the environment variables? Anyhow, this would be a simple matter to resolve, since I can find out which file my system uses and just work with that! Problem is that having identified the file, albeit the "wrong" one, it generates the expected console messages, but doesn't generate a messages to the file handler. I seem to be stuck both ways!

[Ken Krebs]

Simon,
It's probably finding the other jre. Your path should be to the bin directory, i.e. %JAVA_HOME%\bin which is where the java executable is.
The % signs are just the way the Windoze command line demarcate an environment variable from other text.
[ January 16, 2004: Message edited by: Ken Krebs ]

[Simon Ingram]

Hi Ken,
my environment variables are:
JAVA_HOME: c:\j2sdk1.4.1_03\bin
Path = %JAVA_HOME%;.
i.e. I am already pointing at the bin directory. Are you suggesting that if I change my Path to:
Path = %JAVA_HOME%\bin;.
That my system will use the logging.properties file in c:\j2sdk1.4.1_03\jre\lib and not, as presently, the file in c:\Program Files\Java\j2re1.4.1_03\lib?
As Terry pointed out, if you install the Java SDK on a windows XP machine, you get both logging files (I haven't done a second installation). The issue here is which version the system uses. Terry and everyone else find that the logging attaches to the jre/lib version while I am attached to the other. It's wierd and I would like to understand why.

[Ken Krebs]

Simon,
I didn't notice you had JAVA_HOME pointing at the bin directory.
Consider this from the installation instructions:

#
Private vs. public J2RE - Installing the Java 2 SDK installs a private Java 2 Runtime Environment and optionally a public copy. The private J2RE is required to run the tools included with the Java 2 SDK. It has no registry settings and is contained entirely in a jre directory (typically at C:\Program Files\j2sdk1.4.2\jre) whose location is known only to the SDK. On the other hand, the public J2RE can be used by other Java applications, is contained outside the SDK (typically at C:\Program Files\Java\j2re1.4.2), is registered with the Windows registry (at HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft), can be removed using Add/Remove Programs, might or might not be registered with browsers, and might or might not have java.exe copied to the Windows system directory (making it the default system Java platform or not).

The executing jre is probably the public one pointed to by the registry keys. The path entry pointing to the bin dir is for running the JDK tools contained there.
The instructions no longer make any mention of JAVA_HOME as they did in the past. Other programs may want you to set this variable though. These programs will not expect it to be pointed at the bin directory, but at the root of the JDK installation directory.
Also, if you decide to submit your assignment with logging, the tester probably will not want to have to replace their logging.properties with yours.

[Barry Gaunt]

Simon, I agree with Ken, that it is a bad choice putting the bin directory in JAVA_HOME. By convention, and a lot of other java based products depend on it, JAVA_HOME is the installation directory. That is, something like C:\j2sdk1.4.2. On the PATH you use %JAVA_HOME%\bin.
[ January 17, 2004: Message edited by: Barry Gaunt ]

[Simon Ingram]

Ken,
thanks for the information. From what you say, logging is one of the tools in the private j2re, but it is the public j2re that I have registered with windows. This is why the so called "wrong" logging.properties file seems to control the log messages. OK. I don't mind which version the system uses, so long as I know which one it is!
I did as recommended and took the bin off my JAVA_HOME so how I have JAVA_HOME pointing at the private library i.e. c:\j2sdk1.4.1_03 and the path = %JAVA_HOME%\bin;.
The real problem, however, is that I cannot get the messages to go to the file handler! When I start my PC, a bunch of initial logging messages appear in the log file (from Tomcat) but I can't get my console messages to go to the file.
Here is the file, would you please tell me if you see anything that can explain why I don't get messages in c:\Java\CERT\log\URLy.log
it should be straight forward, but for some reason I am haunted by logging!
regards and thanks
Simon
############################################################
# Default Logging Configuration File
#
# You can use a different file by specifying a filename
# with the java.util.logging.config.file system property.
# For example java -Djava.util.logging.config.file=myfile
############################################################
############################################################
# Global properties
############################################################
# "handlers" specifies a comma separated list of log Handler
# classes. These handlers will be installed during VM startup.
# Note that these classes must be on the system classpath.
# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.

# To also add the FileHandler, use the following line instead.
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
# Default global logging level.
# This specifies which kinds of events are logged across
# all loggers. For any given facility this global level
# can be overriden by a facility specific level
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.
.level= ALL
############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################
# default file output is in user's home directory.
java.util.logging.FileHandler.level = ALL
java.util.logging.FileHandler.pattern = /Java/CERT/log/URLy.log
java.util.logging.FileHandler.limit = 50000
# java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
# Limit the message that are printed on the console to INFO and above.
java.util.logging.ConsoleHandler.level = SEVERE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
com.xyz.foo.level = SEVERE
# suncertify.db.level = SEVERE

[Ken Krebs]

Simon,
I'm not sure I understand what you're saying.
Is the file c:\Java\CERT\log\URLy.log being created at all ?

If not, the problem is probably related to the use of the leading forward slash in:
java.util.logging.FileHandler.pattern = /Java/CERT/log/URLy.log
I don't think you can get to the root of the current drive in this way. The reason is probably in the FileHandler.generate(String pattern, int generation, int unique) method.

You can instead try:
java.util.logging.FileHandler.pattern = URLy.log
This should result in a log file created in the current working directory.
Hope that helps. The process is not entirely clear to me and is poorly explained in the Javadoc IMO.

[Simon Ingram]

Hi Ken,
the file c:\Java\CERT\log\URLy.log is created in the right place. The problem is that I get logging messages on the console but not in the logging file. Also I get OTHER logging messages (from Tomcat) in my URLy.log! These are produced when I first start my PC.
Here is a little extract from the end of the log:
FINER: JMX.mbean.registered Catalina:type=Mapper
19-Jan-2004 11:08:54 org.apache.coyote.tomcat5.MapperListener handleNotification
FINE: Handle Catalina:type=Mapper
19-Jan-2004 11:08:54 org.apache.coyote.tomcat5.MapperListener handleNotification
FINE: Handle Catalina:type=Mapper
19-Jan-2004 11:08:54 org.apache.catalina.startup.Catalina start
INFO: Server startup in 184453 ms

I have absolutely no idea where these came from!

[Ken Krebs]

Since you are using the JRE's logging.properties file, you should expect that other Java applications, like Tomcat, may also use it.
The purpose of the JRE's logging.properties file is to provide a DEFAULT logging configuration for ALL Java applications that use logging. For you to expect the tester or other users to change this file to suit your needs is very intrusive behavior. If I were the tester, I probably would give you a big markdown because of it.
As far as not getting messages logged to the file, you will have to post some code that shows how you are accessing the logging system.

[Simon Ingram]

Ken,
I do not want to use the default logging file and following your last post I have restored it to its original condition and I will now leave it alone. I was just trying to get logging going and not having used it before, I followed the advise in Max's book. Problem is, that even though I am issuing logging messages in my code, the only way I can see the messages is by playing with the default config file. I simply don't know how to make the other config file the active one. How do you direct logging messages to a file? It should be a simple matter of of editing the jre/lib version, but as I explained in my first post, when I do nothing happens! I suppose you have seen Terry's post "Is logging really this easy?" I have done everything Terry said, but all I can say is "Is logging really this difficult!"

[Ken Krebs]

Take a look at the LogManager.readConfiguration(InputStream ins) method. Using this, you can read your own logging.properties file without messing around with either the JRE or SDK's version. You can put it and the log file in the dir that you run the app from.

[Simon Ingram]

Ken,
thanks a lot for your patience! I tried your suggestion AND IT WORKS! Which is great, particularly for the project, because as you observed, the examiner would not want to have to tinker with either of the default logging files. But.... I am still puzzled as to why my jre\lib\logging.properties is inactive, because it clearly says in Sun's Javadoc LogManager class definition:
By default, the LogManager reads its initial configuration from a properties file "lib/logging.properties" in the JRE directory. If you edit that property file you can change the default logging configuration for all uses of that JRE.
I also tried the other suggestion, setting the System property as follows:
java.util.logging.config.file=c:\\Java\\CERT\\logging.properties
but no luck! When I do a getProperty, the value is there
c:\Java\CERT\logging.properties
but it doesn't do anything. It is all very frustrating!