Recursos JNDI comunes en Tomcat

Question

Estoy ejecutando un par de aplicaciones de servlet en Tomcat (5.5). Todos los servlets usan un recurso de fábrica común que se comparte usando JNDI. Por el momento, puedo hacer que todo funcione al incluir el recurso de fábrica como GlobalNamingResource en el archivo /conf/server.xml y, a continuación, hacer que el archivo META-INF/context.xml de cada servlet incluya un ResourceLink en el recurso. Los fragmentos de los archivos XML se incluyen a continuación. NOTA: ¡No estoy tan familiarizado con Tomcat, así que no estoy diciendo que esta sea una buena configuración!

Sin embargo, ahora quiero poder instalar estos servlets en múltiples instancias de tomcat automáticamente usando un RPM. El RPM copiará primero los WAR en el directorio de webapps y los jar de fábrica en el directorio common/lib (lo cual está bien). Pero también deberá asegurarse de que el recurso de fábrica esté incluido como recurso para todos los servlets.

¿Cuál es la mejor manera de agregar el recurso globalmente? No estoy muy interesado en escribir un script que vaya al archivo server.xml y agregue el recurso de esa manera. ¿Hay alguna manera de agregar en varios archivos server.xml para que pueda escribir un nuevo archivo server-app.xml y concatenará mi configuración en server.xml? O, mejor aún, agregar este recurso JNDI a todos los servlets sin usar server.xml en absoluto?

p.s. Reiniciar el servidor no será un problema, así que no me importa si los cambios no se recogen automáticamente.

Gracias

de fragmentos de server.xml

<!-- Global JNDI resources --> 
    <GlobalNamingResources> 

    <Resource name="bean/MyFactory" 
       auth="Container" 
       type="com.somewhere.Connection" 
       factory="com.somewhere.MyFactory"/> 
    </GlobalNamingResources> 

archivo/context.xml META-INF de todo el servlet

<?xml version="1.0" encoding="UTF-8"?> 
<Context> 
    <ResourceLink global="bean/MyFactory" 
       name="bean/MyFactory" 
       type="com.somewhere.MyFactory"/> 
    </Context> 

Answer 1

Desde Tomcat 4, la recomendación ha sido no colocar información JNDI en el archivo server.xml. Compruebe :

Para Tomcat 5, a diferencia de Tomcat 4.x, es NO recomienda colocar elementos directamente en el archivo server.xml . Esto se debe a que hace que modifique la configuración de contexto más invasiva ya que el archivo principal conf/server.xml no se puede volver a cargar sin reiniciar Tomcat.

Sé que no se preocupa por esto, pero confíe en mí, su equipo de implementación lo hace, y el equipo de mantenimiento se lo agradecerá más adelante. Incluso si esto significa que terminas agradeciéndote a ti mismo.

Si necesita una configuración JNDI para ser compartida entre todas las aplicaciones web en un servidor, debe ponerla en el archivo $ CATALINA_HOME/conf/context.xml. Con toda probabilidad, ya habrá un context.xml existente en esa ubicación, pero debería poder escribir una aplicación simple para agregar sus nodos de recursos a través de su idioma favorito y cualquier generador de DOM incluido con él. O bien, si desea seguir con la línea de comandos, consulte this article, que ofrece algunos scripts de shell de procesamiento XML para ayudarlo.

¡Buena suerte!

Answer 2

Esto no responde directamente a su pregunta, pero tienen en su lugar, se consideró poner todas las configuraciones dentro del archivo context.xml, en lugar de server.xml? Esto hace que su aplicación web sea más completamente autónoma, lo que parece importante para sus requisitos de implementación.

Me atrevería a decir que valdría la pena considerar cualquier refactorización necesaria para garantizar que sus aplicaciones puedan ser completamente autónomas si esto no se puede hacer en este momento.

Después de haber trabajado en proyectos donde desplegué/comunes/lib JAR y recursos comunes, y me han mordido de manera confusa y sutil (finalmente descubrí que estos eran invariablemente mi culpa, no culpando a Tomcat), ahora estoy a favor de un enfoque completamente protector de mis webapps: mantenlos completamente independientes.

Pero, por supuesto, no conozco completamente sus circunstancias, solo algunas sugerencias.

Answer 3

Esto lo que haría, estoy usando Maven 3, que pondría a la server.xml en mi directorio resources o cualquier otro directorio que puede ejecutar un filter en forma dinámica y reemplazar y generar una adecuada server.xml cuando hago un paquete. A continuación, podría utilizar el plugin maven-rpm y automatizar la generación de rpm también.

Answer 4

En realidad tenemos un caso donde no podemos poner (por ejemplo) configuración jdbc en la guerra: el cliente nunca nos dejará saber el nombre de usuario y la contraseña para el servidor de producción, así que tuvimos que definir la fuente de datos en la configuración del servidor global ponga un enlace en context.xml de la aplicación, como lo hizo el op. La configuración global se puede colocar en server.xml o en context.xml de tomcat (parece que el segundo enfoque es el preferido en la plataforma de Windows).