Me gusta tener, por una parte la instalación “limpia” de Eclipse, y por otra los datos de configuración y los plug-ins.
Para poder conseguir esta separación, siempre utilizo una línea de comando de arranque de Eclipse similar a esta:
/opt/eclipse-3.3.1/eclipse -clean -vm /opt/jdk1.6.0_02/bin/java -configuration /home/rubensa/desarrollo/eclipse-3.3.1/configuration -data /home/rubensa/desarrollo/eclipse-3.3.1/workspace -vmargs -Xms128m -Xmx1024m -XX:MaxPermSize=90m -Dfile.encoding=UTF-8 -Duser.name=rubensa
Donde:
- -clean: Indica que limpie la cache de plug-ins (suelo añadir nuevos plug-ins frecuentemente y es posible que “no se entere”)
- -vm: Indica el path a la JVM a utilizar para ejecutar eclipse
- -configuration: Indica el path en el que guardar los datos de configuración con los que ejecutar Eclipse
- -data: Indica el path del directorio que queremos utilizar por defecto para los proyectos y configuraciones de los mismos
- -vmargs: Parámetros adicionales a pasar a la máquina virtual
- -Xms128m: Usar 128 Mb de memoria inicialmente para la pila (heap) de la JVM
- -Xmx1024m: Usar como máximo 1Gb de memoria para la pila (heap) de la JVM
- -XX:MaxPermSize=90m: Utilizar 90 Mb como espacio de pila permanente de generación (permanent generation heap) (OJO: este parámetro es específico de la JVM de Sun)
- -Dfile.encoding=UTF-8: Juego de caracteres a utilizar por defecto en todos los ficheros (por compatibilidad entre Windows/Linux)
- -Duser.name=rubensa: Nombre de usuario a utilizar (ej: cuando hacemos “commit” en el sistema de control de versiones)
Al instalar el plugin Subclipse de subversion para el IDE Eclipse me encontré con un problema. Por defecto Subclipse utiliza “JavaHL (JNI)” para comunicarse con subversion. Esta configuración por defecto genera el siguiente error cuando se accede a las preferencias “Window->Preferences->Team->SVN”:
Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path
no svnjavahl-1 in java.library.path
no svnjavahl in java.library.path
java.library.path = /opt/jdk1.6.0_02/jre/lib/i386/server:
/opt/jdk1.6.0_02/jre/lib/i386:
/opt/jdk1.6.0_02/jre/../lib/i386:
/usr/lib/firefox/:
/usr/java/packages/lib/i386:
/lib:
/usr/lib
NOTA: como se puede ver en el mensaje utilizo en mi sistema la implementación de Java de Sun.
¿Alguna vez te has encontrado con un error java.lang.OutOfMemoryError: PermGen space failure al re-desplegar tu aplicación en un servidor de aplicaciones? Acusaste al servidor de aplicaciones, mientras lo reiniciabas, para continuar con tu trabajo pensando que claramente se trata de un bug en el servidor de aplicaciones. Esos desarrolladores de servidores de aplicaciones deberían metérselo por donde les quepa, ¿o no? Bueno, quizás. Pero quizás ¡la culpa sea tuya!.
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
06/19/07
¿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.
Tutorial de echo2 en español
04/2/07
Recientemente he traducido el tutorial oficial de Echo2 al español y está disponible en mi página web para todo aquel que esté interesado en introducirse en este framework de desarrollo basado en AJAX.
Threads de Java en Linux
03/7/07
Una de las principales diferencias entre el desarrollo de Linux y otros sistemas operativos UNIX está en la librería de threads (hilos) del sistema. En las versiones de Java 2 anteriores a la 1.3, la JVM utiliza su propia librería de threads, conocida como greenThreads, para implementar los threads en la plataforma Java. La implementación GreenThreads minimiza la exposición de la JVM a las diferencias de a librería LinuxThreads y consigue que el porte sea más sencillo de conseguir. Lo malo del GreenThreads es que no se aprovechan los threads de Linux, de modo que la JVM no se escala bien al añadir nuevas CPUs.
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.
Acceder a JBoss usando NAT
01/31/07
Tengo en una máquina virtual un servidor JBOSS en el que he desplegado varios EJBs y una aplicación Java Web Start que hace uso de dichos EJBs.
El problema es que desde otro equipo no tengo acceso a la máquina virtual ya que está en una subred propia, pero lo que puedo hacer es configurar por NAT (para que las peticiones a los puertos de mi máquina real se redirijan a los de la máquina virtual) los siguientes puertos:
- 1099: servicio de JNP
- 1098: puerto RMI
- 4444: RMIObjectPort
Además, hay que añadir en el arranque del servidor JBOSS los siguientes parámetros:
- -Djava.rmi.server.hostname=<external_host_name>
- -Djava.rmi.server.useLocalHostname=false
donde <external_host_name> es el nombre de mi máquina “real” (que es la que ve el resto del mundo).
Algunos enlaces de interés
UsingJBossBehindAFirewall
java.rmi Properties
RMI: Running the Example Programs
SSH Tunneling for Java RMI, Part-II
NAT, RMI, -Djava.rmi.server.hostname, is there a client solution instead?
Accessing Applications across Firewalls
RMI Through Firewalls Via Proxies
Is it possible to replace the java-rmi.cgi script that comes with the JDK distribution with a servlet?
APACHE - Tomcat - RMI HTTP TUNNELLING HOW-TO
