Должен ли логгер Log4J быть объявлен временным?

Регистратор должен быть статическим; это сделало бы его несериализуемым.

Нет причин делать регистратор нестатичным, если только у вас нет для этого веских причин.

Как насчет использования статического регистратора? Или вам нужна отдельная ссылка на регистратор для каждого экземпляра класса? Статические поля по умолчанию не сериализуются; вы можете явно объявить поля для сериализации с помощью частного статического окончательного массива ObjectStreamField с именем serialPersistentFields. См. Документацию Oracle

Добавлен контент: Поскольку вы используете getLogger (getClass ()), вы будете использовать один и тот же регистратор в каждом экземпляре. Если вы хотите использовать отдельный регистратор для каждого экземпляра, вы должны различать имя регистратора в методе getLogger (). например getLogger (getClass (). getName () + hashCode ()). Затем вы должны использовать атрибут transient, чтобы убедиться, что регистратор не сериализован.

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

Если вы хотите, чтобы Logger был для каждого экземпляра, тогда да, вы бы хотели сделать его временным, если вы собираетесь сериализовать свои объекты. Регистраторы Log4J не сериализуемы, ни в какой версии Log4J, которую я использую, так или иначе, поэтому, если вы не сделаете свои поля Logger временными, вы получите исключения при сериализации.

Регистраторы не сериализуемы, поэтому вы должны использовать переходный процесс при их сохранении в полях экземпляра. Если вы хотите восстановить регистратор после десериализации, вы можете сохранить уровень (String) в отдельном объекте, который сериализуется.

Такие случаи, особенно в EJB, обычно лучше всего обрабатываются через локальное состояние потока. Обычно вариант использования - это что-то вроде того, что у вас есть конкретная транзакция, в которой возникла проблема, и вам нужно повысить уровень ведения журнала для отладки для этой операции, чтобы вы могли создать подробный журнал для проблемной операции. Перенести некоторое локальное состояние потока через транзакцию и использовать его для выбора правильного регистратора. Честно говоря, я не знаю, где было бы полезно установить уровень для INSTANCE в этой среде, потому что отображение экземпляров в транзакцию должно быть функцией уровня контейнера, вы фактически не будете контролировать, какой экземпляр используется в в любом случае данная транзакция.

Даже в тех случаях, когда вы имеете дело с DTO, обычно не рекомендуется проектировать вашу систему таким образом, чтобы требовался конкретный конкретный экземпляр, потому что дизайн может легко развиваться таким образом, что это плохой выбор. Вы можете прийти через месяц и решить, что соображения эффективности (кэширование или какая-либо другая оптимизация изменения жизненного цикла) нарушит ваше предположение о отображении экземпляров в единицы работы.

Либо объявите поле регистратора как статическое, либо как временное.

Оба способа гарантируют, что метод writeObject () не будет пытаться записать поле в выходной поток во время сериализации.

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

Если вы В самом деле хотите использовать переходный подход, вам нужно будет сбросить журнал, когда ваш объект десериализуется. Для этого нужно реализовать метод:

 private void readObject(java.io.ObjectInputStream in) 
   throws IOException, ClassNotFoundException;

В javadocs для Сериализуемый есть информация об этом методе.

Ваша реализация будет выглядеть примерно так:

 private void readObject(java.io.ObjectInputStream in) 
     throws IOException, ClassNotFoundException {
   log = Logger.getLogger(...);
   in.defaultReadObject();
 }

Если вы этого не сделаете, то после десериализации вашего объекта журнал будет нулевым.

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

(Как уже упоминалось, используйте статические или переходные).