views:

513

answers:

2

I've an issue with a project I try to deliver using the one-jar packager to simplify the deployment process.
Without the packaging, everything works fine and the logging configuration is perfectly loaded, but within the packaging, only part of the configuration is appied.

So, here is the logging.properties I use:

handlers= java.util.logging.ConsoleHandler, java.util.logging.FileHandler
.level= INFO
java.util.logging.FileHandler.pattern = C:\\MyPath\\logging.csv
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = my.package.logging.Formatter
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = my.package.logging.Formatter

And In my main class, here is how I load it:

public class MainClass {
  public static void main(final String[] args) {
    try {
      LogManager.getLogManager().readConfiguration(
        new MainClass().getClass().getResourceAsStream("logging.properties"));
      // main process goes here.
    } catch(Exception e) {
      // Exception handling
    }
  }
}

The log level as well as the FileHandler pattern are well understood because the logging ends up in the correct file, but as row XML output, which makes me think that the formatter is not loaded as it normally outputs a CSV format.

Could it be related to a classpath issue? Does anyone knows how to handle this?

+1  A: 

It could be in your jars you have more than one logging.properties file, with similar but slightly different settings. When you combine them with one-jar the order changes and one of them gets hidden. Do a "jar -tf *.jar |grep logging.properties" and see what you see.

If that doesn't work can you try unjarring the onejar result to a directory structure, and then running with the directory on the classpath instead of the jar? That will let you see if it is something to do with the jar, and actually inspect the logging.properties you have in the onejar, and see if it matches what you expect.

Nick Fortescue
Nice try, but this is the only "logging.properties" I have.
gizmo
OK. I've had this before when one of my third party jars had a logging.properties in that I didn't realise. Next suggestion - added as an edit ...
Nick Fortescue
A: 

Use LogManager.getLogManager().readConfiguration(LogManager.class.getResourceAsStream("/logging.debug.properties"));

(note the extra slash).

gliptak