Load java.util.logging.config.file for default initialization

Question

I'm trying to load a custom log.properties file when my application is started.

My properties file is in the same package as my main class, so I assumed that the -Djava.util.logging.config.file=log.properties command line parameter should get the properties file loaded.

But the properties are only loaded when i specify a full absolute path to the properties file. Any suggestions how to use a relative path?

Velar

Answer 1

Java logging doesn't search your whole hard disk for a file; there are very simple rules how files are looked up. You want Java to see that the two files belong to each other but you didn't say so anywhere. Since Java sees no connection between the properties file and your class other than that they are in the same folder on your disk, it can't find the file.

-Djava.util.logging.config.file=log.properties only works if the file log.properties is in the current directory of the Java process (which can be pretty random). So you should use an absolute path here.

An alternate solution would be to move the file logging.properties into $JAVA_HOME/lib/ (or edit the file which should be there). In that case, you don't need to set a System property.

Isotope

Hi, thanks for the answer. I'm just beginning with java, so i don't know a lot about packaging etc. I have a NetBeans default project with a package called javaapplication. The log.properties file is in the default package now. So my command line looks like this: JavaApplication\dist>javaw -Djava.util.logging.config.file=log.properties -jar JavaApplication.jar The properties file still isn't loaded. Could you give me an additional hint please? :) – Velar

Are you sure it's not loaded? "javaw" swallows all output to System.out and System.err. Try "java" instead (without "w"). Also, you can try to debug the code to see why it's not logging. Just set a breakpoint and "step into" the logging call (instead of "step over"). log4j offers a debug option which makes it print the config as it reads it; I don't know if you can do the same with java.util.logging. – Isotope

Thanks for the reply. I think i'll stick to runtime configuration through a class, because i can't get the properties file to load with a relative path. – Velar

This answer is incorrect. You cannot simply put the file at the working directory or on the classpath. You have to specify either java.util.logging.config.file or java.util.logging.config.class; otherwise it will look in $JAVA_HOME. See the readConfiguration method in java.util.logging.LogManager. – Strip

@BrianGordon: You're absolutely right. I think I mixed that up with loading the properties using getResourceAsStream() which LogManager doesn't do. Fixed. – Isotope

Answer 2

You can dynamically load java.util.logging properties files from a relative path very easily. This is what I put inside a static {} block in my Main class. Put your logging.properties file in the default package and you can access it very easily with the following code.

final InputStream inputStream = Main.class.getResourceAsStream("/logging.properties");
try
{
    LogManager.getLogManager().readConfiguration(inputStream);
}
catch (final IOException e)
{
    Logger.getAnonymousLogger().severe("Could not load default logging.properties file");
    Logger.getAnonymousLogger().severe(e.getMessage());
}

Zingaro

Great, exactly what I looked for and works like a charm! – Revetment

using "/logging.properties" will cause getResourceAsStream() to return null. You should just use "logging.properties" - the class loader considers everything relative to the class path and doesn't consider the collection of class path elements as "/". – Roussillon

Answer 3

util logging does not load from classpath, it needs an absolute path which is why other logging packages like log4j are far easier to configure and better for web apps where it's a pain to get abs paths.

this is not explained at all in the java.util.logging.LogManager doco.

Emoryemote

(years later, after jul is finally understood better :-) ) it certainly doesn't require an absolute path; but it is a file path (relative or absolute); as an alternative you can have a class feed properties to the LogManager (loaded from the classpath as one would expect) instead of loading them from a file, by using -Djava.util.logging.config.class={class} instead of -Djava.util.logging.config.file=path/to/my.properties But I think everyone can agree that java.util.logging is a bit raw and that ---log4j--- (update) slf4j+logback is easier to configure and better logging option – Pedant