Можно ли оправдать нестатический журнал?

Question

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

Все классы содержат следующие два импорта:

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

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

/** The log. */
private Log log = LogFactory.getLog(Xyz.class);

Можно ли это оправдать?

Можно ли безопасно сменить все это на статические вызовы?

РЕДАКТИРОВАТЬ Относительноособые случаи, когда это (очевидно) может быть полезно: мой вопрос действительно более «Можно ли оправдать нестатический журнал во всей кодовой базе?»

Answer 1

Это зависит.Это из документации :

Обратите внимание, что для кода приложения объявление члена журнала как "статического" более эффективно, поскольку для каждого класса создается один объект журнала, и рекомендуется,Однако это небезопасно для класса, который может быть развернут с помощью «общего» загрузчика классов в контейнере сервлета или j2ee или аналогичной среде.Если класс может быть вызван с другими значениями потока-контекста-загрузчика классов, то член не должен быть объявлен статическим.Поэтому следует избегать использования «статического» кода в любом проекте типа «библиотека».

Answer 2

Вы должны быть особенно осторожны с инициализацией нестатических регистраторов, как ваш фрагмент кода работает в Serializable классах.

Во-первых, потому что Log не сериализуем, поэтому любая попытка сериализации вашего класса также потерпит неудачу. Если вы объявите свой регистратор transient, то, как это логично, ваше поле log не будет инициализировано после десериализации, поэтому вы получите NPE при попытке записать материал. Не очень хорошая ситуация.

Таким образом, чтобы подвести итог, вы можете иметь нестатические регистраторы, если хотите, но убедитесь, что они инициализированы, прежде чем использовать их. Но кроме этого, я бы не стал сильно беспокоиться о нестатических регистраторах, большинство реализаций журналирования всегда все равно будут возвращать один и тот же объект регистратора (log4j определенно это делает).

Answer 3

Один экземпляр, где нестатический регистратор удобен, это своего рода базовый класс, который предоставляет экземпляр журнала дочерним классам (для удобства). Рассмотрим следующий пример:

public abstract class Pet
{
   protected Log log;

   public Pet()
   {
      log = LogFactory.getLog(this.getClass());
   }

   public void wash()
   {
      log.info("Get the hose.");
   }
   ...
}

public class Cat extends Pet
{
   ...
   public void doSomethingUseful()
   {
      log.warn("I can't, I am a cat.");
   }
}

В этом примере ведение журнала будет происходить из экземпляра журнала «Cat». Является ли это действительным обоснованием отказа от использования статического регистратора? Может быть, не для сообщений, зарегистрированных в классе Cat, но сообщения, зарегистрированные в классе Pet в экземпляре журнала Cat, могут быть полезны.

Answer 4

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

Однако рассмотрим случай, когда класс, использующий "private static Log log = ...", развернут через ClassLoader, который находится в предке несколькихякобы самостоятельные "приложения".В этом случае элемент журнала инициализируется только один раз, поскольку существует только одна копия класса.Эта инициализация (как правило) происходит в первый раз, когда любой код пытается создать экземпляр этого класса или вызвать статический метод для него.Когда происходит инициализация класса, какой элемент журнала должен быть установлен?

http://wiki.apache.org/commons/Logging/StaticLog