Manter session no bean EJB 3.1 com estado?

Estou trabalhando em um webapp Java tentando combinar as seguintes tecnologias:

  • Java EE 6
  • CDI
  • JSF 2
  • EJB 3.1
  • Spring Security

Eu forneço beans de apoio baseados em CDI (@ViewScoped, @Named) para minhas páginas JSF.

Eu uso beans EJB @Stateless para o trabalho real a ser feito.

Eu só preciso de algumas informações de session como jSessionCookie (gerenciado pelo contêiner), nome de usuário interno e alguns outros IDs internos. Agora, pergunto-me onde colocar essas informações da session para que eu possa acessá-las nos beans de apoio do JSF, mas também fornecê-las aos EJBs sem estado? Devo usar um bean de session EJB @Stateful ou devo criar um POJO com base em CDI com @SessionScoped e @Named?

Existem melhores práticas?

Para seu caso de uso específico, um bean de session com informações de estado não seria uma boa escolha.

Observe que, ao contrário do que as pessoas podem reivindicar, os beans de session com informações de estado certamente não são algo que você deve evitar. No entanto, eles são para casos de uso avançado, por exemplo, ao lidar com o contexto de persistência estendida do JPA.

A razão pela qual os beans de session com estado não funcionariam aqui é que eles não são automaticamente associados à session HTTP, o que parece ser sua principal preocupação. Você pode adicionar a anotação @SessionScoped a eles, mas também pode usar um bean gerenciado regular. Você não usaria nenhum dos resources específicos de um SFSB.

Veja alo:

  • Posso usar o EJB Stateless Bean com CDI para manter a session do usuário?
  • Usando um bean de session com monitoração de estado para rastrear a session de um usuário
  • Chamando um método produtor com escopo da session de CDI a partir de um bean de session sem estado do EJB
  • Injeção de Dependência e Contextos no Java EE 6

Você pode injetar seus EJBs stateless com um bean CDI com escopo de session, mas é necessário perceber que dentro do mesmo aplicativo seu bean EJB dependeria da session HTTP (algo que às vezes você deseja evitar, por exemplo, se seu bean tiver que ser chamado de outros contextos também).

@Estateful EJB é algo que eu tentaria ficar longe. Eu acredito que comportamento e estado são coisas que não devem ser misturadas.

Eu também iria para a resposta de SJuan76 e usaria o bean backing SessionScoped JSF.