Есть ли в JSF2 обратный вызов для активации/деактивации сеансового компонента?

Я хочу реализовать обратный вызов для компонента сеанса в JSF2/CDI, если компонент был активирован или деактивирован контейнером.

Эти методы я хочу использовать для запуска транзакции в EJB. Сам EJB имеет состояние, управляется bean-компонентом с помощью расширенного контекста транзакции.

Есть обратный вызов (PostConstruct), который вызывается после создания бина из контейнера CDI.

Мой Бин выглядит примерно так:

@javax.inject.Named
@javax.enterprise.context.SessionScoped
public class MyBean implements Serializable {

  @EJB private MyEJB myEJB;

  public MyBean () {
    super ();
    // do someting more (or not)
  }

  @PostConstruct
  public void init () {
    // do something for init ...
  }

  public void businessMethod () {
    // ..
  }
}

Метод @PostConstruct вызывается только один раз в начале жизненного цикла.

Я хочу получать информацию от контейнера, когда bean-компонент (повторно) активируется при запуске запроса или bean-компонент «припаркован» в конце запроса.

Я думаю, что @PreDestroy здесь не решение.

Спасибо вам за помощь.

С уважением Рональд


person Ronald    schedule 07.12.2015    source источник
comment
@PreDestroy? google.com/search?q=cdi+bean+session+ деактивация+обратный вызов   -  person Kukeltje    schedule 07.12.2015
comment
@Kukeltje: я не хочу получать информацию о жизненном цикле EJB (@PostActivate, @PreDestroy), но когда контейнер пробуждает JSF-бин. Но, возможно, это возможность. Или у JSF Beans нет жизненного цикла?   -  person Ronald    schedule 07.12.2015
comment
"проснуться" в смысле? Вы пометили вопрос с помощью destroy и cdi и с областью сеанса, это то, что я использовал в запросе в google, и @PreDestroy в bean-компоненте CDI кажется подходящим для этого (и я нигде не упоминал EJB...). Ваше разъяснение помогает, но теперь это не дубликат того, что было дублировано как... Итак, вы имеете в виду что-то вроде @PrePassivate/@PostActivate, которое существует для EJB? Нет такой вещи, что они не в пулах, не «припаркованы» и/или вообще не проснулись... Каков фактический вариант использования?   -  person Kukeltje    schedule 07.12.2015
comment
хорошо, тег «уничтожить» был создан не вами и добавлен после моего комментария, но на самом деле я думал, что это имелось в виду ... Я могу снова открыть вопрос, но сначала уточните   -  person Kukeltje    schedule 07.12.2015
comment
@Kukeltje: Хорошо, у меня есть JSF-Bean (SessionScope) со ссылкой на один или несколько EJB (все они имеют состояние, управляются компонентами с расширенным контекстом сохранения). Я хочу получать информацию от контейнера, когда мой JSF-бин активируется в запросе и деактивируется в конце запроса. Таким образом, фундаментальный вопрос заключается в том, что у JSFBean есть жизненный цикл, как и у EJB. Если да, то есть ли способ подключиться к этому жизненному циклу, как это возможно с EJB. Если нет, то я должен искать другой путь.   -  person Ronald    schedule 07.12.2015
comment
У вас есть управляемый компонент CDI, а не управляемый компонент JSF (вы используете аннотацию @Named, а не @ManagedBean). И да, у них есть жизненный цикл, как вы уже знаете, благодаря аннотациям @PostConstruct и @PreDestroy. Но они не объединены в пул, как EJB, поэтому при каждом запросе нет «активации» или «деактивации». Sessionbean используется, если вызывается один из его методов, вот и все. Но, пожалуйста, укажите реальный вариант использования (нетехнический)... Зачем вам это нужно? Вы первый, кто задает этот вопрос, поэтому я думаю, что это meta.stackexchange.com/questions/66377/what-is-the-xy-problem   -  person Kukeltje    schedule 07.12.2015
comment
@Kukeltje: Хорошо, ты прав. Не JSF, а управляемый компонент CDI. И bean-компоненты CDI не объединяются, например, EJB. Под «активацией» я имел в виду время обработки запроса, в течение которого CDI извлекается из сеанса HTTP. При первом запросе это вызов PostConstruct. Но я думаю, что я сделал ошибку здесь. В основном я ищу идею того, как я знаю в CDI-компоненте, на каком этапе запроса (JSF) обрабатывается мое текущее местоположение. Создание CDI-компонента для PhaseListener — очень плохая идея, потому что во время создания экземпляра PhaseListener EJB не внедряется.   -  person Ronald    schedule 08.12.2015
comment
Вы можете получить текущую фазу из FacesContext… но все же, каков вариант использования   -  person Kukeltje    schedule 08.12.2015
comment
@Kukeltje: Спасибо за заметку с FacesContext. У меня была идея, которая позволила бы мне избавиться от раздражающего исключения ленивой инициализации. Приложение старше и имеет очень плохой дизайн. Имеет ужасно большие сети объектов. Object_a ссылается на список экземпляров object_b, которые могут ссылаться (как список) снова на экземпляры Object_C. В клиенте мне нужно все дерево/сеть объектов в самых редких случаях. Это жестоко.   -  person Ronald    schedule 08.12.2015