Tengo un programa/subproceso de Java que deseo implementar en un servidor de aplicaciones (GlassFish). El hilo debe ejecutarse como un "servicio" que se inicia cuando el servidor de aplicaciones se inicia y se detiene cuando se cierra el servidor de aplicaciones.Enhebrado en un servidor de aplicaciones
¿Cómo voy a hacer esto? No es realmente un Session Bean o MDB. Es solo un hilo.
Crea un servlet cuyo método init inicia un hilo que es el programa principal.
public void init() throws ServletException {
mailThread = new MailSendThread();
mailThread.start();
}
En el archivo web.xml de nuestra aplicación añadir un servlet que incluye un elemento de carga-on-startup donde el número es el orden en el que se inicia.
<servlet>
<servlet-name>Mail Sending Servlet</servlet-name>
<servlet-class>MailServlet</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
esto no es algo que se debe hacer en cualquier servidor de aplicaciones, a menos que tenga acceso a los subprocesos administrados proporcionados por el servidor de aplicaciones. No estoy familiarizado con Glassfish, pero puedes hacerlo en Websphere o Weblogic usando Commonj WorkManager.
Aparentemente, lo mismo se puede lograr en Glassfish y JBOSS a través de un JCA WorkManager (con el que no estoy familiarizado).
Solo he hecho esto con Tomcat, pero debería funcionar en Glassfish.
Cree una clase Listener que implemente javax.servlet.ServletContextListener, luego póngalo en web.xml. Se le notificará cuando su aplicación web se inicie y se destruya.
Una simple clase Listener:
public class Listener implements javax.servlet.ServletContextListener {
MyThread myThread;
public void contextInitialized(ServletContextEvent sce) {
myThread = new MyThread();
myThread.start();
}
public void contextDestroyed(ServletContextEvent sce) {
if (myThread != null) {
myThread.setStop(true);
myThread.interrupt();
}
}
}
Esto va en web.xml después de su última 'context-param' y antes de su primera 'servlet':
<listener>
<listener-class>atis.Listener</listener-class>
</listener>
no saben si este tipo de cosas se recomienda o no, pero me funcionó en el pasado.
Esto me parece mucho más limpio que el secuestro de un método servlet.init(). Aún así, me siento un poco incómodo al iniciar subprocesos en un AppServer. – Guillaume
+1 esta es la forma de hacerlo. si no se siente cómodo con la administración de su propio hilo ... inicie el uso del cuarzo dentro del servidor de la aplicación. pero hazlo dentro del SCL como se describe aquí. –
Nice. Funciona en Glassfish 3 aquí. –
También necesito para crear varios hilos, donde cada hilo se abrirá una toma a otra procesos remotos que ejecutan en mi aplicación GlassFish. Servidor. Analicé el bean LifecycleListener provisto por Glassfish que necesita implementar.
Creé un prototipo para realizar el trabajo de enhebrado y socket en la implementación de LifecycleListener y realmente no ayudó con la gestión de estos recursos. Para tener acceso al LifecycleListener, tuve que poner , un método público estático que ejecutaba las acciones deseadas.
No veo ningún valor en LifecycleListener porque podría haber realizado exactamente el mismo trabajo dentro de mi EJB, que es el cliente que llama al LifecycleListener. Porque realmente no hay una gestión adecuada del hilo y el zócalo en el grano.
Me dijeron que JCA puede ser el mejor camino a seguir. No he intentado esto.
Comienzo un objeto temporizado con el servicio de temporizador y solo una sola caducidad. Luego, en el tiempo de espera, hago lo que quería hacer con el hilo.
http://onjava.com/pub/a/onjava/2004/10/13/j2ee-timers.html
Para mí funcionó ya que utiliza componentes J2EE y es un hilo diferente.
Curiosidad: ¿por qué necesitas comenzar un hilo? Siempre me siento mal cuando tienes que iniciar subprocesos en un AppServer ... – Guillaume
El hilo es ejecutar una instancia de HSQL DB Server – systemoutprintln