session - Uso de un bean de sesión con estado para rastrear la sesión de un usuario

ejb javabeans

Question

Es mi primera pregunta aquí y espero que lo esté haciendo bien.

Necesito trabajar en un proyecto Java EE, así que, antes de comenzar, estoy tratando de hacer algo simple y ver si puedo hacerlo.

Estoy atrapado con Beans Stateful Session .

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 bean es STATEFUL, ¿por qué tengo que usar HttpSession para conservarlo?

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

Lo he intentado con un simple frijol contador. Sin usar la sesión, dos navegadores diferentes tienen el mismo bean de contador (al hacer clic en "incremento" se cambió el valor de ambos). Usando sesión, tengo dos valores diferentes, cada uno para cada navegador (haciendo clic en "incrementar" en Firefox, agregando uno solo al bean de Firefox).

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

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

¡Espero que mi (s) pregunta (s) sea 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 desaparezcan mis datos! He intentado agregar HttpSession mientras se registra, pero hacerlo de esta manera hace que los datos permanezcan incluso después del cierre de sesión.

Answer 1

Debe 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;
}
}

Echa un vistazo a los siguientes (se explica en detalle)

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

Answer 2

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

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

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

En el caso de una aplicación web, cuando un navegador realiza 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 mantener este JSESSIONID , el navegador puede proporcionarlo con cada solicitud de seguimiento y esto activará el mismo servidor de la sesión http.

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

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

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 del 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 de cliente que accede al SFSB debe "aferrarse" a una referencia de proxy específica. Mantener algo en la capa web normalmente significa almacenarlo en la sesión HTTP.

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