Деактивировать Geotools INFO входит в JAR - PullRequest
0 голосов
/ 08 ноября 2018

Я использую Geotools (версия 19.2) для получения некоторых функций. Чтобы отключить регистрацию Geotools (

  1. Как я понял, документация по протоколированию ( страница документации ):

Logging.getLogger("org.geotools").setLevel(Level.SEVERE);

  1. Загрузка пользовательской конфигурации logging.properties

Конфигурация ( logging.properties ) выглядит следующим образом:

# standard log level
.level = WARNING

handlers = java.util.logging.ConsoleHandler

## limit the messages that are printed on the console to >= WARNING!
java.util.logging.ConsoleHandler.level = WARNING
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.ConsoleHandler.encoding = Cp850

# do not use logging files!
java.util.logging.FileHandler.level = OFF

## just output geotools logs with level SEVERE!
org.geotools.level = SEVERE

Затем я загружаю конфигурацию, используя этот код:

LogManager.getLogManager().readConfiguration(MyMainClass.class.getClassLoader().getResourceAsStream("logging.properties"));

Используя оба подхода, я получаю НЕТ вывода журнала, если я запускаю свою программу в Eclipse . Если я запускаю свою программу как JAR -файл, я получаю следующий нежелательный вывод журнала :

ноябрю 08, 2018 9:48:13 VORM. org.geotools.jdbc.JDBCDataStore getAggregateExpression INFO: класс посетителя org.geotools.feature.visitor.CountVisitor не имеет статистического атрибута.

Журнал INFO находится с private Expression getAggregateExpression(FeatureVisitor visitor) в JDBCDataStore (см. GitHub )

Есть идеи, почему конфигурация регистрации не работает для сгенерированного JAR?

1 Ответ

0 голосов
/ 09 ноября 2018

Использование JConsole (следующий ответ о подавлении ведения журнала утилит java от стороннего jar ) Я обнаружил, что моя конфигурация журналирования была перезаписана моим установочным файлом Java logging.properties .

Я попытался изменить конфигурацию ведения журнала в моем основном методе, что было неверно.

Инициализация пользовательских свойств logging.properties в отдельном классе и указание необходимого системного свойства решает проблему!

  1. Пользовательский класс инициализации

    public class CustomLoggingPropertiesLoader {

    // Initialize the global LogManager
    public CustomLoggingPropertiesLoader() {
        try {
            LogManager.getLogManager().readConfiguration(CustomLoggingPropertiesLoader.class.getClassLoader().getResourceAsStream("logging.properties"));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    

    }

  2. Использовать системное свойство ("Java).util.logging.config.class ")

java -Djava.util.logging.config.class = de.example.logging.CustomLoggingPropertiesLoader -classpath [myclasspath]

...