30

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?

Gilles 'SO- stop being evil'
  • 104,111
  • 38
  • 209
  • 254
abp
  • 385
  • 1
  • 3
  • 11

3 Answers3

57

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());
}
  • 2
    Great, exactly what I looked for and works like a charm! – fxnn Dec 03 '14 at 10:00
  • 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 "/". – Guss Dec 23 '18 at 09:38
22

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.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • 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? :) – abp Apr 30 '09 at 08:36
  • 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. – Aaron Digulla May 07 '09 at 14:30
  • 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. – abp May 12 '09 at 07:09
  • 5
    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`. – Rag Dec 28 '13 at 01:09
  • @BrianGordon: You're absolutely right. I think I mixed that up with loading the properties using `getResourceAsStream()` which `LogManager` doesn't do. Fixed. – Aaron Digulla Jan 08 '14 at 13:18
8

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.

user280033
  • 89
  • 1
  • 2
  • 2
    (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 – michael Feb 27 '13 at 04:12