Изменение переменных экземпляра в объединенных фазах без состояния [дубликат]

Question

Изменение переменных экземпляра в объединенных фазах без состояния [дубликат]

Одна вещь:

Очень важно отметить, что строка с закрывающим идентификатором Heredoc не должна содержать других символов, кроме точки с запятой (;). Это означает, что идентификатор не может быть отступом и не может быть никаких пробелов или вкладок до или после точки с запятой.

Пример:

   $str = <<<EOD
Example of string
spanning multiple lines
using heredoc syntax.
EOD;

11

java ejb cdi specifications stateless-session-bean

задан BalusC 27 August 2014 в 07:03

1 ответ

Другие вопросы по тегам:

java ejb cdi specifications stateless-session-bean

Похожие вопросы:

score 17 · Accepted Answer

Означает ли это, что каждый новый UserLoginView получает новый экземпляр UserService?

Нет. Данный UserService является [E3] EJB. @Stateless EJB объединяются и вводятся в виде сериализуемых прокси-серверов, автогенерируемых контейнером. Среди прочего, доказательством этого является трассировка стека, когда исключение происходит из EJB. Вы видите дополнительные уровни между методом бэкэн-бобов и методом EJB.

Созданный автогенерируемый класс прокси для @Stateless EJB выглядит примерно так (на самом деле он более сложный, например, транзакция DB также должна быть получена , начато и зафиксировано здесь):
public class UserServiceProxy extends UserService implements Serializable {

    public User find(Long id) {
        UserService instance = getAnAvailableInstanceFromPool();
        User result = instance.find(id);
        releaseInstanceToPool(instance);
        return result;
    }

    public Long save(User user) {
        UserService instance = getAnAvailableInstanceFromPool();
        Long result = instance.save(user);
        releaseInstanceToPool(instance);
        return result;
    }

    // ...
}
Вы видите это? Он просто захватывает доступный экземпляр из пула EJB, а затем делегирует вызов метода ему и, наконец, выпускает его в пул для последующего повторного использования. Это именно этот экземпляр прокси, который фактически вводится в ваш JSF-управляемый bean-компонент.

CDI тоже работает, кстати. Именно поэтому с CDI можно вводить компонент более узкой области в компоненте более широкого диапазона и все равно заставить его работать как намеренный. JSF @ManagedBean внедряет экземпляр actual , и поэтому он не работает таким образом. Это сработало бы, если бы JSF также использовал прокси-серверы, которые фактически захватили текущий экземпляр компонента через FacesContext и делегировали ему.

Только @Stateful EJB фактически привязаны к времени жизни клиента. В случае управляемого компонента в качестве клиента он действительно получит «свой» экземпляр. См. Также Объект, обработанный JSF-запросом, поддерживает воссоздание новых сессионных компонентов Stateful для каждого запроса?

Хорошо реализовать его так, как это, в производственной среде ?

Абсолютно. В противном случае они не существовали.