Buscar
Social
Ofertas laborales ES

Foro sobre Java SE > Event Listener en client socket?

Hola a todos y antes de nada, muchas gracias por perder unos minutos y leer esto. Estoy necesitando implementar un socket, el cual tengo un listener que me avise que me enviaron datos desde el socket server. El inconveniente mas grande es que necesitaria que no tenga threads porque estoy utilizando bases de datos y haria mas engorroso todo.

Acepto sugerencias y nuevamente gracias!
Emiliano

marzo 9, 2015 | Unregistered CommenterEmiliano

La manera habitual de añadir un soporte de eventos a una clase cualquiera es como sigue:

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

public class Test {

private transient final PropertyChangeSupport propertyChangeSupport = new PropertyChangeSupport(this);

/**
Add PropertyChangeListener.
<p>
@param listener
*/
public void addPropertyChangeListener(PropertyChangeListener listener) {
propertyChangeSupport.addPropertyChangeListener(listener);
}

/**
Remove PropertyChangeListener.
<p>
@param listener
*/
public void removePropertyChangeListener(PropertyChangeListener listener) {
propertyChangeSupport.removePropertyChangeListener(listener);
}

}

Una vez que añadas el código relevante, puedes usar los métodos de PropertyChangeSupport para disparar los eventos cuando sean necesarios.

http://docs.oracle.com/javase/8/docs/api/java/beans/PropertyChangeSupport.html

Lo que no entiendo es qué tienen que ver las threads con ésto, y aún entiendo menos por qué el uso de bases de datos se hace más engorroso si se usan.

marzo 9, 2015 | Registered Commenterchoces

Te puedo proponer otra alternativa, porque lo sockects para hacer eso que tu dices me parece demasiado complicado. Además como tu dices tendrías que gestionar los hilos para las peticiones concurrentes que te llegan y liberarlos adecuadamente. Vamos que a mi los sockets no me convencen.

Por que no utilizar WebServices, el cliente realiza una llamada a tu servidor con una serie de parámetros de entrada y tu servicio hace lo que tenga que hacer en BD y devuelve una respuesta al cliente diciendo que todd ha ido bien o mal.

Con sockets a pelo hacer eso es mucho más complicado, en el fondo un webservices no es más que un socket pero con una serie de tecnología ya probada y testeada que hace que todos los canales se comuniquen perfectamente y las conexiones e hilos se cierren sin problemas y no haya timeout engorrosos.

Saludo.

marzo 10, 2015 | Registered Commenterantuansoft

@antuansoft
Quizá lo haya entendido mal pero me ha parecido que Emiliano el problema lo tiene en el cliente, no en el servidor.
Por lo que he entendido lo que hace es abrir desde el cliente un socket al servidor y espera que de vez en cuando el servidor le mande algo. Creo que lo que a el le gustaría es no quedarse a la espera y que cuando el servidor le mande algo le avise.

Lo que no entiendo es lo de no usar Threads. No veo que problema puede tener.

Un saludo,
Paposo

marzo 11, 2015 | Unregistered CommenterPaposo