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

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

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

 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();
 }

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

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

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

Или объявите свое поле регистратора как статичное или как переходный процесс.

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

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

Эти виды случаев, особенно в EJB, обычно лучше всего обрабатываются через поток локальное состояние. Обычно вариант использования, что-то как Вы имеет конкретную транзакцию, которая встречается с проблемой, и необходимо поднять вход для отладки для той операции, таким образом, можно генерировать подробное вхождение в систему операции задач. Несите некоторый поток локальное состояние через транзакцию и использование что выбрать корректный регистратор. Откровенно я не знаю, где это было бы выгодно для установки уровня на ЭКЗЕМПЛЯРЕ в этой среде, потому что отображение экземпляров в транзакцию должно быть контейнерной функцией уровня, Вы не будете на самом деле иметь контроля, которого экземпляр используется в данной транзакции так или иначе.

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

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

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

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

(Как другие упомянули использование, статичное или переходное).