Historial de página

...

<fw:socket> es un componente UI que abre una conexión push basada en websocket unidireccional (de servidor a cliente) en el lado del cliente a la que se puede acceder desde el lado del servidor a través de la interfaz PushContext inyectada mediante la anotación @Push.

...

Observar estos eventos en componentes de ámbito EVENT/PAGE/SESSION no tiene sentido, ya que no se puede realizar una solicitud HTTP en ese momento.

@Name("socketObserver")
@Scope(ScopeType.APPLICATION)
public class SocketObserver {

    @Observer( SocketEvent.EVENT_SOCKET_OPENED )
    public void onOpen(SocketEvent event) {
        String channel = event.getChannel(); // Returns <fw:socket channel>.
        Long userId = event.getUser(); // Returns <fw:socket user>, if any.
        SocketEvent.EventType type = event.getEventType(); // Valid values: OPENED, SWITCHED, CLOSED
        // Do your thing with it. E.g. collecting them in a concurrent/synchronized collection.
        // Do note that a single person can open multiple sockets on same channel/user.
    }

    @Observer( SocketEvent.EVENT_SOCKET_SWITCHED )
    public void onSwitch(SocketEvent event) {
        String channel = event.getChannel(); // Returns <fw:socket channel>.
        Long currentUserId = event.getUser(); // Returns current <fw:socket user>, if any.
        Long previousUserId = event.getPreviousUser(); // Returns previous <fw:socket user>, if any.
        SocketEvent.EventType type = event.getEventType(); // DoValid yourvalues: thingOPENED, withSWITCHED, it. E.g. updating CLOSED 
        // Do your thing with it. E.g. updating in a concurrent/synchronized collection.
    }

    @Observer( SocketEvent.EVENT_SOCKET_CLOSED ) 
    public void onClose(SocketEvent event) {
        String channel = event.getChannel(); // Returns <fw:socket channel>.
        Long userId = event.getUser(); // Returns <fw:socket user>, if any.
        SocketEvent.EventType type = event.getEventType(); // Valid values: OPENED, SWITCHED, CLOSED 
        CloseCode code = event.getCloseCode(); // Returns close reason code.
        // Do your thing with it. E.g. removing them from collection.
    }

}

...

public final class PushEventMyPushEvent implemmentsimplements orges.um.jbossatica.seamfaces.corepush.EventObjectPushEvent {

    private final String messageuser; 

    private publicfinal PushEvent(String message);  {


    public MyPushEvent(String message) {
        this(null, message);
    } 

    public MyPushEvent(String user, String message) {
        this.messageuser = messageuser;
        this.messag e= message; 
    }

    public String getMessage() {
        return message;
    }
}
    public String getUser() {
        return user;
    } 
}

Después, utiliza Después, utiliza org.jboss.seam.core.Events.raiseEvent(org.jboss.seam.core.EventObject), para lanzar el evento

...

Es importante advertir, que el componente con ámbito EVENT, no debe ser el mismo que el de la página de origen, por la sencilla razón de que no hay forma de realizar una solicitud HTTP en ese momento.  Por esa misma razón, un componente con ámbito PAGE o SESSION, no funcionaría (ya que requieren respectivamente el estado de vista Faces y la sesión HTTP que solo se pueden identificar mediante una solicitud HTTP). Una conexión push con ámbito de view o session, tampoco funcionaría, por lo que la conexión push realmente debe tener ámbito  application. El FacesContext tampoco estará disponible en el método que recibe el evento anterior.

En caso de que el disparador del evento del backend EAR/EJB sea un método de servicio asincrónico, que a su vez se inicia en el lado WAR, entonces puede hacer uso de callbacks del lado WAR. Deje que el método de servicio tome una instancia de callback como parámetro, como por ejemplo, la interfaz java.util.function.Consumer.

...

Esta sería la única forma en caso de que desee enviar de forma asincrónica un mensaje a una conexión push con ámbito de view o session, y/o desee pasar algo desde FacesContext o de ámbito EVENT/PAGE/SESSION como argumento (con modificador final).

Sugerencias de Diseño

...

de la UI

Si se quieren realizar actualizaciones complejas de la UI, la forma más sencilla es usando <f:ajax> dentro de <fw:socket>. Ejemplo:

<h:panelGroup id="foo">
    ... (some complex UI here) ...
</h:panelGroup>

<h:form>
    <fw:socket channel="someChannel" scope="view">
        <f:ajax event="someEvent" listener="#{bean.pushed}" render=":foo" />
    </fw:socket>
</h:form>

Donde el mensaje push, solo contien el nombre del evento Ajax. Puedes usar cualquier nombre de evento personalizado.

someChannel.send("someEvent");

Otra alternativa, es combinar <fw:socket> con <p:remoteCommand>, ejemplo:

<h:panelGroup id="foo">
    ... (some complex UI here) ...
</h:panelGroup>

<fw:socket channel="someChannel" scope="view" onmessage="someCommandScript" />
<h:form>
    <p:remoteCommand name="someCommandScript" action="#{bean.pushed}" update=":foo" />
</h:form>

Si se pasa un Map<String, V> o un POJO (JAVABEAN) como el objeto en el mensaje push, después todas las entradas/propiedades estarán disponibles como parámetros de la solicitud en la acción del comando #{bean.pushed}.

Sugerencias de Diseño en Cluster

En el caso que la aplicación este desplegada en un cluster con varios nodos, y el evento push se lanza desde un nodo diferente al que esta conectado el cliente (Navegador Web), entonces este no será notificado. Una solución es usar temas (topic) JMS, lanzar el evento push a través de JMS, y usar MDB (message driven bean) para reenviar el evento push a JBoss Seam en cada nodo.


Con JBoss Seam tenemos varios componentes para ayudar a trabajar con JMS. Ejemplo para la configuración de JMS con JBoss Seam, en el fichero components.xml registramos el manager del tema (topic) JMS, como norma general, el nombre del tema  comenzara con el nombre de la aplicación en minúsculas seguido de PushTopic, en el ejemplo usaremos pruebaPushTopic. Para el nombre del publisher, podemos usar el nombre que queramos. Veamos un ejemplo de configuración:

<jms:managed-topic-publisher name="pushPublisher" 

<jms:managed-topic-publisher name="pruebaPushPublisher" 
                             auto-create="true" 
                             topic-jndi-name="topic/pruebaPushTopic"/>

Ahora se puede inyectar el componente pruebaPushPublisher en cualquier componente:

@Name("pushChangeNotifier")
public class PushManager {

   @In
   private TopicPublisher pruebaPushPublisher;   

   @In
   private TopicSession topicSession;

   public void fireEvent(PushEvent event) {
        try {
           pruebaPushPublisher.publish(topicSession.createObjectMessage(event.getMessage()));
        } catch (Exception ex) {
           throw new RuntimeException(ex);
        } 
   }

}

...

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(
        propertyName = "destinationType",
  auto-create="true" installDependencies="es.um.atica.faces.push.pushInitialization"
                             topic-jndi-name="jms/pruebaPushTopic"/>
<jms:topic-connection topic-connection-factory-jndi-name="jms/pruebaPushConnectionFactory"
	        propertyValue  = "javax.jms.Topic"
    ),
    @ActivationConfigProperty(
        propertyName = installDependencies="es.um.atica.faces.push.pushInitialization"/>

Ahora se puede inyectar el componente pushPublisher en cualquier componente:

@Name("pushEventsManager "destination",
        propertyValue = "topic/pruebaPushTopic"
    )
})
@Name("pushReceiver")
public class pushReceiver implementsPushEventsManager MessageListener {

   @Logger@In
   private LogTopicPublisher logpushPublisher;   

   @In
   @Overrideprivate TopicSession topicSession;

   public void onMessagefireEvent(MessagePushEvent jmsMessageevent) {
        try {
          String message = jmsMessage.getStringProperty("message");
         Events.instance().raiseEvent(new PushEvent(message));
      } catch (JMSException ex) {
         log.error("Problem sending push event message.", ex);
      } 
   }

}

...

  pushPublisher.publish(topicSession.createObjectMessage(event.getMessage()));
        } catch (Exception ex) {
           throw new RuntimeException(ex);
        } 
   }

}

Para recibir los mensajes JMS tenemos que configurar un MDB:

package es.um.atica.prueba.push;

import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;

import org.jboss.seam.annotations.Logger;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.core.Events;
import org.jboss.seam.log.Log;
import org.jboss.seam.util.Strings;

import es.um.atica.faces.push.PushEvent;

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(
        propertyName = "destinationType",
        propertyValue = "javax.jms.Topic"
    ),
    @ActivationConfigProperty(
        propertyName = "destinationLookup",
        propertyValue = "jms/pruebaPushTopic"
    )
})
@Name("pushReceiver")
@TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED)
public class PushReceiver implements MessageListener {

	@Logger
	private Log log;

	protected void raiseEvent(String eventType, PushEvent event) {
		if (Strings.isEmpty(eventType)) {
			log.info("Raise push event '#0'", event.getClass().toString());
			Events.instance().raiseEvent(event);
		} else {
			log.info("Raise push event '#0'", eventType);
			Events.instance().raiseEvent(eventType, event);
		}
	}

	@Override
	public void onMessage(Message jmsMessage) {
		try {
			String eventType = jmsMessage.getStringProperty("eventType");
			PushEvent event = jmsMessage.getBody(PushEvent.class);
			raiseEvent(eventType, event);
		} catch (JMSException ex) {
			log.error("Problem sending push event message.", ex);
		}
	}

}

Ahora, usamos PushManager#fireEvent() para lanzar eventos JMS desde un nodo del cluster, que permite después lanzar los eventos de JBoss Seam en todos los nodos el cluster y asi enviar el mensaje al canal push correspondiente:

@In
private PushEventsManager pushEventsManager;

public void onSomeEntityChange(Entity entity) {
    pushEventsManager.fireEvent(new MyPushEvent(entity.getSomeProperty()));
}

Todas estas clases, están añadidas en las librerías de FundeWeb, y el sistema también esta añadido a partir del Arquetipo versión 2.0.11, que añade un perfil llamada cluster que permite terne fácilmente esta funcionalidad. Solo tendréis que usar el PushEventsManager para enviar los mensajes a través de las conexiones push. Para añadir esa configuración a una aplicación existente hay que descargar el fichero push-cluster.zip y descomprimir con Extraer aquí en la raíz  del proyecto. Con esto crearemos la carpeta web/src/main/profiles/cluster.

En esta carpeta tendremos la carpeta java donde se encuentra la clase PushReceiver (la única que no esta en las librerías de FundeWeb). La ruta a esta clase, es/um/atica/__rootArtifactId__/push (que es una ruta de paquete de código fuente), la tendremos que modificar, cambiando __rootArtifactId__ por el identificador de la aplicación. En la propia clase PushReceiver, tendremos que cambiar los valores ${rootArtifactId} por el identificador de la aplicación (igual que antes).

También tenemos que modificar el fichero web/src/main/profiles/cluster/components.xml, tendremos que cambiar los valores ${rootArtifactId} por el identificador de la aplicación (igual que antes).

Para finalizar, en el POM del módulo Web, tendremos que añadir un perfil a <profiles> (el elemento XML puede estar comentado, por lo que dejamos sin comentar solo las etiquetas <profiles> y </profiles>):

		<profile>
			<id>cluster</id>

			<properties>
				<cluster.profile.folder>src/main/profiles/cluster</cluster.profile.folder>
			</properties>

			<build>
				<plugins>
					<plugin>
						<groupId>org.codehaus.mojo</groupId>
						<artifactId>build-helper-maven-plugin</artifactId>
						<executions>
							<execution>
								<id>add-cluster-java</id>
								<phase>generate-sources</phase>
								<goals>
									<goal>add-source</goal>
								</goals>
								<configuration>
									<sources>
										<source>${cluster.profile.folder}/java</source>
									</sources>
								</configuration>
							</execution>
						</executions>
					</plugin>

					<plugin>
						<groupId>be.hikage.maven.plugins</groupId>
						<artifactId>maven-xmlmerger-plugin</artifactId>
						<executions>
							<execution>
								<id>merge-cluster-components_xml</id>
							    <phase>generate-resources</phase>
								<goals>
									<goal>mergexml</goal>
								</goals>
								<configuration>
									<baseDirectory>${basedir}/src/main/webapp/WEB-INF</baseDirectory>
									<inputDirectory>${cluster.profile.folder}/xmlmerge</inputDirectory>
									<outputDirectory>${basedir}/src/main/webapp/WEB-INF</outputDirectory>
									<mergeFilenamePattern>()(components\.xml)</mergeFilenamePattern>
								</configuration>
							</execution>
						</executions>
					</plugin>
				</plugins>
			</build>

			<dependencies>
				<dependency>
					<groupId>es.um.atica.fundeweb</groupId>
					<artifactId>fundeweb-cluster</artifactId>
				</dependency>
			</dependencies>
		</profile>

Para finalizar, tenemos que poner un JIRA a DJ-AT-SIST-MIDDLE (MIDWEB), como Petición de Servicio y al componente JMS, indicando que hay que crear una cola JMS para la aplicación XXXXX con rutas JNDI:

• Para el Tema (TOPIC): jms/_nombre_aplicacion_minusculas_PushTopic
• Para la fábrica de conexiones: jms/_nombre_aplicacion_minusculas_PushConnectionFactory

Más información sobre JMS:

• JMS Setup In Weblogic 12c
• Video - Weblogic JMS Configuration
• Como configurar un tema (topic) JMS en el servidor Weblogic 12.2.
• Como ver los mensjaes de un tema (topic) JMS en el servidor Weblogic 12.2.

Configuraciones Adicionales Obligatorias

Para que las peticiones push puedan ser interceptadas por JBoss Seam, tenemos que hacer una configuración adicionales en los ficheros components.properties y components.xml.

Tenemos que ver el atributo para especificar la URL que se intercepta para los filtros: <web:exception-filter>, <web:logging-filter>, <web:character-encoding-filter>.

Si se usa el atributo url-pattern, para este caso añadimos la propiedad default_url_pattern en el fichero components.properties, con el valor definido para la propiedad junto con la que se usa para las peticiones push, si por ejemplo, el valor de la propiedad es *.seam, entonces añadimos:

default_url_pattern=*.seam|/fundeweb.push/*

Ahora en el fichero components.xml, para los filtros;<web:exception-filter>, <web:logging-filter>, <web:character-encoding-filter>; cambiamos el valor del atributo por @default_url_pattern@. Ejemplo:

   <!-- Exception handling -->
    <web:exception-filter url-pattern="@default_url_pattern@" installed="true" />

    <!-- Identity Logging -->
    <web:logging-filter url-pattern="@default_url_pattern@" installed="true" />

    <!-- Character encoding -->
    <web:character-encoding-filter encoding="UTF-8"
        override-client="true" installed="true" url-pattern="@default_url_pattern@" />

Si se usa el atributo regex-url-pattern, para este caso añadimos la propiedad default_regex_url_pattern en el fichero components.properties, con el valor definido para la propiedad junto con la que se usa para las peticiones push, si por ejemplo, el valor de la propiedad es .*\.seam, entonces añadimos:

default_regex_url_pattern=.*\.seam|/fundeweb.push/.*

Ahora en el fichero components.xml, para los filtros;<web:exception-filter>, <web:logging-filter>, <web:character-encoding-filter>; cambiamos el valor del atributo por @default_regex_url_pattern@

@In
private PushManager pushManager;

public void onSomeEntityChange(Entity entity) {
    pushManager.fireEvent(new PushEvent(entity.getSomeProperty()));
}

...

• Como configurar un tema (topic) JMS en el servidor Weblogic 12.2.
• Como ver los mensjaes de un tema (topic) JMS en el servidor Weblogic 12.2.

Sugerencias de Diseño de la UI

Si se quieren realizar actualizaciones complejas de la UI, la forma más sencilla es usando <f:ajax> dentro de <fw:socket>. Ejemplo:

<h:panelGroup id="foo">
    ... (some complex UI here) ...
</h:panelGroup>

<h:form>
    <fw:socket channel="someChannel" scope="view">
        <f:ajax event="someEvent" listener="#{bean.pushed}" render=":foo" />
    </fw:socket>
</h:form>

Donde el mensaje push, solo contien el nombre del evento Ajax. Puedes usar cualquier nombre de evento personalizado.

someChannel.send("someEvent");

...

   <!-- Exception handling -->
    <web:exception-filter regex-url-pattern="@default_regex_url_pattern@" installed="true" />

    <!-- Identity Logging -->
    <web:logging-filter regex-url-pattern="@default_regex_url_pattern@" installed="true" />

    <!-- Character encoding -->
    <web:character-encoding-filter encoding="UTF-8"
        override-client="true" installed="true" regex-url-pattern="@default_regex_url_pattern@" />

Además, en el fichero componens.xml, añadimos la siguiente línea (junto al resto de definiciones de <web:context-filter>):

   <web:context-filter name="pushSockets" url-pattern="/fundeweb.push/*" />

...

<h:panelGroup id="foo">
    ... (some complex UI here) ...
</h:panelGroup>

<fw:socket channel="someChannel" scope="view" onmessage="someCommandScript" />
<h:form>
    <p:remoteCommand name="someCommandScript" action="#{bean.pushed}" update=":foo" />
</h:form>

Si se pasa un Map<String, V> o un POJO (JAVABEAN) como el objeto en el mensaje push, después todas las entradas/propiedades estarán disponibles como parámetros de la solicitud en la acción del comando #{bean.pushed}.