Нужно закрыть дополнительный FileHandler для JUL? - PullRequest
0 голосов
/ 13 мая 2011

Я использую ведение журнала Java-утилиты для входа в небольшое приложение Java EE. Чтобы добавить дополнительный FileHandler (например, для ошибок / предупреждений), я создал LoggerFactory, который создает фактический регистратор и статически добавляет обработчик файлов в «основной» регистратор.

package de.il.myapp.logging;

public class LoggerFactory {

    private static final java.util.logging.Logger MAIN_LOGGER = java.util.logging.Logger.getLogger("de.il.myapp");

    static {
            try {
                final java.util.logging.FileHandler fh = new java.util.logging.FileHandler("error.log", 1024*1024, 5, true);
                fh.setLevel(Level.WARNING);

                final java.util.logging.Formatter formatterTxt = new java.util.logging.SimpleFormatter();
                fh.setFormatter(formatterTxt);
                MAIN_LOGGER.addHandler(fh);

            } catch (final IOException e) {
                //...
            }
        }
    }

    public static final Logger getLogger(final Class<?> clazz){
        return java.util.logging.Logger.getLogger(clazz);
    }
}

Все отлично работает, кроме того, что когда я останавливаю приложение, файл lck все еще там. На старте создается новый lck. Таким образом, после некоторого перезапуска каталог выглядит следующим образом.

  error.log.0
  error.log.0.1
  error.log.0.1.lck
  error.log.0.2
  error.log.0.2.lck
  error.log.0.3
  error.log.0.3.lck
  error.log.0.lck

Вопрос: как я могу избежать этого? Должен ли я закрыть обработчик файлов в конце? Но где? Поскольку это приложение Java EE, я не являюсь точкой выхода, не так ли? И почему я получаю ..log.0.X для файлов журналов, а не только ..log.0?

Спасибо, Инго

Ответы [ 2 ]

0 голосов
/ 15 мая 2011

В Glassfish вы можете использовать Слушатели жизненного цикла .В JBoss вы можете использовать StartupServiceMBean.Какой сервер приложений вы используете?

0 голосов
/ 15 мая 2011

Прежде всего вам не разрешено использовать java.io классы в EJB:

Раздел 21.2.2 спецификации:

Корпоративный компонент не должен использовать javaПакет .io для попытки доступа к файлам и директориям в файловой системе.

Это означает, что вам также не следует использовать классы, которые в свою очередь используют классы java.io, если вы не получили их, задав запросконтейнер.

Однако, если вы создаете загруженный одноэлементный сессионный компонент и выполняете очистку @PreDestroy:

@Startup 
@Singleton 
public class FileHandlerCloser {

 @PreDestroy
 public void closeFileHandlers() {
  // close file handlers
 }

}

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

...