Cuando getRealPath() devuelve null
03/09/2009
Cuando desplegamos un módulo web (.war) en los servidores de aplicaciones WebLogic o JBoss puede aparecernos un problema en nuestra aplicación y es que la llamada al método getRealPath(resource) de la clase ServletContext, nos devuelva un null.
Para generar un certificado podríamos hacer lo siguiente (sustituyendo los valores apropiados para el sistema real):
- Borramos el antiguo (si es que existe):
%JAVA_HOME%\bin\keytool -delete -alias tomcat -keypass changeit - Generamos el nuevo certificado de nombre “tomcat” (con esto Tomcat ya encontraría el certicado para poder arrancar con el conector SSL activado):
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keypass changeit -keyalg RSA
NOTA: cuando pregunte el nombre y apellido es necesario especificar “localhost” para que todo funcione bien ya que esto se convertirá en el Common Name (CN) que debe ser el nombre de tu host para que el verificador de nombres de host de Sun valide correctamente -de otro modo lanzará una excepción javax.servlet.ServletException: HTTPS hostname wrong: should be <localhost>- - Exportamos el certificado para poder instalarlo en el equipo cliente:
%JAVA_HOME%\bin\keytool -export -alias tomcat -keypass changeit -file server.crt - Importamos el certificado del servidor Tomcat en el equipo cliente:
%JAVA_HOME%\bin\keytool -import -file server.crt -keypass changeit -keystore %JAVA_HOME%/jre/lib/security/cacerts
Algunos enlaces de interés
help:::HTTPS hostname wrong: should be <localhost>
Using axis with https and a self signed certificate
keytool – Key and Certificate Management Tool
Enterprise Java Bean over SSL
Portecle
Configuring SSL on IBM WebSphere 6.0x
La documentación de JBoss es muy pobre. Para empezar, la documentación oficial solamente está disponible comprándola. El principal problema es que la mayoría de desarrolladores, aun habiendo comprado y leído la documentación oficial, no sabrán cual es la mejor manera de empaquetar sus aplicaciones J2EE para JBoss. La web está llena de historias de terror de desarrolladores que no consiguieron averiguar cómo evitar los problemas de los classloaders (cargadores de clases). La mayoría acaban por colocar todos los jars de los que dependen en el directorio lib global de su servidor. Pero esto viola claramente las consideraciones de ámbito y aumenta los riesgos de conflictos entre aplicaciones no relacionadas entre sí pero descargadas en un mismo contenedor. Por ejemplo, si dos aplicaciones necesitan diferentes versiones de un mismo jar, esta solución requeriría del uso de dos servidores JBoss diferentes.
Este documento es un esfuerzo por recoger las averiguaciones obtenidas en un JBoss 3.2.1 de tal modo que:
- Usuarios más expertos en JBoss puedan decidir si esta es o no la mejor estrategia.
- Otros puedan hacer uso de las averiguaciones aquí descritas y así evitar redescubrir la rueda.
Tomcat common/lib vs. shared/lib
19/06/2007
¿Cuál es la diferencia entre los directorios common/lib y shared/lib de Tomcat?
Dicho de forma simple, common/lib contiene los archivos jar que serán usados tanto por el servidor web como por la aplicaciones web; mientreas que shared/lib contiene los archivos jar que están disponibles para todas las aplicaciones web desplegadas (pero no para el servidor).
Su ámbito es confuso. Es dificil a divinar a partir de los nombre (common y shared -comun y compartido-), cual es el propósito de cada uno. De echo ambos directorios están al mismo nivel ($CATALINA_HOME/common $CATALINA_HOME/shared) lo que lo hace más confuso aún. Si el directorio shared estuviese bajo $CATALINA_HOME/webapp, sería obvio que es para que sea compartido por todas las aplicaciones web.
Si modificamos el nombre de la máquina en la que tenemos instalado un WebSphere Application Server 5, debemos actualizar su configuración para reflejar dicho cambio de nombre.
Entramos en la consola administrativa (http://localhost:9090/admin) y:
- Seleccionamos Servidores –> Servidores de aplicaciones
- Seleccionamos server1
- En la sección Propiedades adicionales, seleccionamos Puntos finales
- Para cada uno de los nombres de puntos finales debemos modificar el valor de Sistema principal para reflejar el nuevo nombre de la máquina.
En esta entrada doy las pasos a seguir para realizar una instalación básica de este servidor de aplicaciones, incluyendo el establecimiento de un sistema de seguridad sencillo basado en la seguridad del propio sistema operativo.
Origen de datos JNDI en Tomcat
11/10/2006
Si estás tratando de configurar un origen de datos JNDI en Tomcat (a partir de la versión 5.5) y recibes un mensaje tal que así:
org.apache.tomcat.dbcp.dbcp.SQLNestedException
Cannot create JDBC driver of class ‘ ‘ for connect URL ‘null’
tal vez te ocurra lo que me sucedió a mí y es que resulta que ya no se utilizan los “resource-params” que se solían usar (en versiones anteriores a la 5.5). Ahora solamente se pueden definir los recursos JNDI mediante atributos.
Hay que cambiar esto:
<Context …>
…
<Resource name=”jdbc/EmployeeDB” auth=”Container”
type=”javax.sql.DataSource”/>
<ResourceParams name=”jdbc/EmployeeDB”>
<parameter>
<name>username</name>
<value>dbusername</value>
</parameter>
<parameter>
<name>password</name>
<value>dbpassword</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>org.hsql.jdbcDriver</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:HypersonicSQL:database</value>
</parameter>
<parameter>
<name>maxActive</name>
<value>8</value>
</parameter>
<parameter>
<name>maxIdle</name>
<value>4</value>
</parameter>
</ResourceParams>
…
</Context>
Por esto:
<Context …>
…
<Resource name=”jdbc/EmployeeDB” auth=”Container”
type=”javax.sql.DataSource” username=”dbusername” password=”dbpassword”
driverClassName=”org.hsql.jdbcDriver” url=”jdbc:HypersonicSQL:database”
maxActive=”8″ maxIdle=”4″/>
…
</Context>
NOTA: Si además, lo que queremos es que nuestro origen de datos esté accesible para toda aplicación web, basta con que la definición del recurso y sus parámetros se pongan dentro de la etiqueta <DefaultContext></DefaultContext> de la definición del <Host name=”localhost”></Host> del archivo server.xml.
Si te has descargado una versión demo de este producto y te ha caducado el periodo de prueba, al arrancar, te saldrá un mensaje indicándote que utilices una licencia o vuelvas a instalar el producto.
Para solucionar esto, y no tener que volver a realizar la instalación completa, simplemente hay que eliminar el archivo:
was.license
del directorio:
properties
de la instalación del WebSphere Application Server (al menos es así para la versión 5).
Haciendo esto el propio WAS creará una nueva licencia temporal al ser arrancado (como si se acabase de instalar).
