Child pages
  • Exponiendo Aplicaciones Web en puertos distintos
Skip to end of metadata
Go to start of metadata

top

Podrías requerir el ejecutar aplicaciones web distintas en puertos distintos. Por ejemplo, podrías requerir una aplicación de administración en un puerto distinto al de una aplicación de producción.

Este ejemplo también demuestra como iniciar a escuchar en los puertos después de que las aplicaciones web han sido completamente activadas y están listas a ser usadas.

Ejemplo con Tomcat

En tomcat no-geronimo puedes hacerlo con incluir dos ó más definiciones de servidor en tu archivo server.xml, e incluyendo las aplicaciones en los elementos servidor. Es posible preparar esencialmente la misma estructura en geronimo.

He aquí una aplicación ejemplo:

http://issues.apache.org/jira/secure/attachment/12334215/appPerPort.ear

Si la desempacas la puedes activar en sitio (inplace) con algo como

java -jar bin/deployer.jar deploy --inPlace appPerPort.ear
(Asumiento que previamente ingresaste al deployer)

A continuación se muestra el plan, con un poco de explicación. Lo primero es que los gbeans en el ear enfocan el inicio; esto inicia 2 servidores tomcat pero sin conectores para ellos.

Después las tres aplicaciones web inician en orden. Las dos primeras son aplicaciones web con contenido. Nota que cada una tiene un gbean-link web-container hacia el contenedor web apropiado que acaba de iniciar.

La tercer aplicación web tiene el conector gbeans para los contenedores web que iniciamos. Nota que las aplicaciones web son módulos así como el ear en si mismo, y que los módulos web inician en el mismo orden en el cual esten listados en application.xml. Recuerda también que para que un módulo pueda iniciar, todos sus gbeans deben iniciar completamente. Por ende, primero tenemos el inicio de los contenedores tomcat, después la activación de las aplicaciones web hacia distintos contenedores tomcat, y finalmente al completar el inicio de las aplicaciones web, los conectores que abren listeners en los dos puertos distintos.

Colocando al conector gbeans en una aplicación web no vacía tiene éxito en la demora de la apertura de puertos hasta después de que las aplicaciones estén listas, pero no es propiamente elegante. Si deseas tener más que un módulo, puedes colocar al conector gbeans en un plan de servicio y enlistar al ear como una dependencia para obtener el mismo efecto.

xmlsolidgeronimo-application.xml geronimo appPerPort-tomcat 1.1-SNAPSHOT car geronimo tomcat car war1.war false TomcatWebContainer1 war2.war false TomcatWebContainer2 connectors.war false HTTP localhost 8081 8192 150 25 75 false 8453 100 20000 false TomcatWebContainer1 HTTP localhost 8082 8192 150 25 75 false 8453 100 20000 false TomcatWebContainer2 var/catalina TomcatEngine1 ServerInfo TomcatWebManager org.apache.geronimo.tomcat.TomcatEngine name=Geronimo1 TomcatHost1 TomcatHost1 TomcatJAASRealm org.apache.catalina.core.StandardHost name=localhost appBase= workDir=work var/catalina TomcatEngine2 ServerInfo TomcatWebManager org.apache.geronimo.tomcat.TomcatEngine name=Geronimo2 TomcatHost2 TomcatHost2 TomcatJAASRealm org.apache.catalina.core.StandardHost name=localhost appBase= workDir=work ]]>

Jetty

Aplicaciones web en Jetty tienen la misma capacidad de especificar qué contenedor jetty debería ser usado, sin embargo, no tenemos un plan ejemplo para demostrar su funcionamiento.

Es posible que exista una forma más simple para limitar en qué puertos esta disponible una aplicación en un contenedor web jetty, por lo cual en jetty no se requerirían dos contenedores jetty. Lo anterior requiere mayor investigación.

  • No labels