Usar un Bean de sesión Stateful para rastrear la sesión de un usuario

es mi primera pregunta aquí y espero hacerlo bien.

Necesito trabajar en un proyecto Java EE, entonces, antes de comenzar, bash hacer algo simple y ver si puedo hacer eso.

Estoy atrapado con Stateful Session Beans .

Aquí está la pregunta: ¿Cómo puedo usar un SFSB para rastrear la sesión de un usuario? Todos los ejemplos que vi terminaron en “poner” el SFSB en un atributo HttpSession . ¡Pero no entiendo por qué! Quiero decir, si el frijol es ESTATAL, ¿por qué tengo que usar la HttpSession para guardarlo?

¿No es tarea de un contenedor EJB devolver el SFSB correcto al cliente?

Lo intenté con un simple contador Bean. Sin usar la sesión, dos navegadores diferentes tienen el mismo contador de beans (al hacer clic en “incrementar” se cambia el valor para ambos). Al usar la sesión, tengo dos valores diferentes, cada uno para cada navegador (haciendo clic en “incrementar” en Firefox, agregué uno solo al bean de Firefox).

Pero mi maestra dijo que un SFSB mantiene el “estado de conversación con un cliente”, ¿por qué no funciona sin usar una HttpSession ?

Si lo entendí correctamente, ¿no usar HttpSession con un SFSB es lo mismo que hacerlo con un SLSB ?

¡Espero que mi (s) pregunta (s) sea (n) clara (s) y que mi inglés no sea tan pobre!

EDITAR: estoy trabajando en un sistema de inicio de sesión. Todo va bien y después de completar el inicio de sesión me lleva a una página de perfil que muestra los datos del usuario. ¡Pero volver a cargar la página hace que mis datos desaparezcan! ¡He intentado agregar HttpSession al iniciar sesión, pero al hacerlo de esta manera, los datos se mantienen incluso después del cierre de sesión!

Un Stateful Session Bean (SFSB) tiene que combinarse con la sesión HTTP en un entorno web, ya que es un negocio puro que no sabe nada de la capa web.

Tradicionalmente los EJB incluso obligatorios vivían dentro de su propio módulo (el módulo EJB), que ni siquiera podía acceder a artefactos web si querían. Este es un aspecto de los sistemas estratificados. Consulte Embalaje EJB en JavaEE 6 WAR vs EAR para obtener más información al respecto.

Los clientes originales para Stateful Session Beans fueron, entre otras, las aplicaciones de escritorio Swing, que se comunicaban con el servidor EJB remoto a través de un protocolo binario. Una aplicación Swing obtendría una conexión a un bean de sesión Stateful remoto a través de un objeto proxy / stub. Incluido en este proxy hay una identificación de algún tipo que el servidor puede asociar con un SFSB específico. Al aferrarse a este objeto proxy, el cliente Swing puede realizarle llamadas repetidas y éstas irán a la misma instancia de bean. Esto creará una sesión entre el cliente y el servidor.

En el caso de una aplicación web, cuando un navegador hace una solicitud inicial a una aplicación web Java EE obtiene un JSESSIONID que el servidor puede asociar con una instancia específica de HTTPSession . Al aferrarse a este JSESSIONID , el navegador puede proporcionarle con cada solicitud de seguimiento y esto activará la misma sesión http del lado del servidor.

Entonces, esos conceptos son muy similares, pero no se mapean automáticamente entre sí.

El navegador solo obtiene el JSESSIONID y no tiene conocimiento sobre ninguna ID de SFSB. A diferencia de la aplicación Swing, el navegador se comunica con páginas web, no directamente con beans Java.

Para asignar la solicitud del cliente a un bean de sesión con estado específico, el contenedor EJB solo se preocupa por la ID proporcionada a través del proxy SFSB. No puede ver si la llamada se originó a partir de un código en el módulo web y no puede / no debería realmente acceder a ningún contexto HTTP.

La capa web que es el código del cliente que accede al SFSB debe ‘retener’ una referencia de proxy específica. Aferrarse a algo en la capa web normalmente significa almacenarlo en la sesión HTTP.

Sin embargo, hay una tecnología de puente llamada CDI que puede hacer esta conexión automática. Si anota su SFSB con @SessionScoped de CDI y obtiene una referencia al SFSB a través de CDI (por ejemplo, usando @Inject ), no tiene que colocar manualmente su SFSB en la sesión http. Sin embargo, detrás de escena CDI hará exactamente eso de todos modos.

Necesita definir el bean con @SessionScoped en lugar de @RequestScoped (si está buscando una solución equivalente a HttpSession)

algo como

 @SessionScoped public class SessionInfo implements Serializable{ private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } 

Eche un vistazo a lo siguiente (explicado en detalle)

http://www.oracle.com/technetwork/articles/java/cdi-javaee-bien-225152.html