7 de setiembre de 2014

Cómo eliminé Java completamente de OS X

A lo largo del tiempo y de las actualizaciones, he acumulado algunas máquinas virtuales de Java (JVM) en mi Mac con OS X. Desde el tiempo que Apple proporcionaba Java, he intentado mantener las instalaciones bajo control, pero de alguna manera terminé teniendo varias instaladas. Así que me puse a hacer limpieza.

Sabía que el plugin de Java para applets se instalaba una ruta diferente que los kits de desarrollo (JDK) que había bajado, pero no sabía dónde. Así que me puse a buscarlos:
  1. Entré como un usuario administrador (normalmente uso un usuario estándar.)
  2. Abrí una terminal, y abrí un shell como root:
  3. Busqué todos los archivos que tuvieran java en su nombre:
  4. De los resultados, quité todos los que tenían que ver con directorios internos de NetBeans, Xcode, VirtualBox y archivos adjuntos de Mail y mis proyectos de desarrollo:
    /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java	⇒ 1.8.0_20
    
    /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java		⇒ 1.7.0_45
    
    /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java		⇒ 1.7.0_51
    
    /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java		⇒ 1.8.0
    
    /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java		⇒ 1.8.0_05
    
    /System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java		⇒ 1.8.0_05
    
    /usr/bin/java		→ /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
    
    Después de las flechas dobles, incluyo la versión de Java que se muestra cuando se ejecuta java -version en cada ruta. La última ruta es una liga simbólica.
    La primera de las rutas, la que contiene JavaAppletPlugin.plugin, es el ambiente de ejecución (JRE) que se instala para ejecutar los applets y se actualiza automáticamente. Los JDK no se actualizan automáticamente.
  5. Finalmente, borré tanto el plugin de Java como todos los JDK:
    rm -rf /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin
    rm -rf /Library/Java/JavaVirtualMachines/
    rm -rf /Library/Application\ Support/Oracle/
    rm -rf /Library/Java
    
  6. Después de eso, bajé e instalé el JDK más reciente, que en mi caso fue Java 8 update 20.

18 de junio de 2014

Cómo aumentar la memoria a NetBeans

Para aumentar la memoria que usa NetBeans 7.2, modifiqué el siguiente archivo:

[NETBEANS_DIRECTORY]/etc/netbeans.conf

Agregué los siguientes valores a la propiedad "netbeans_default_options":

-J-Xms800m -J-Xmx800m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled

No modifiqué el parámetro -J-XX:PermSize=32m.

30 de abril de 2014

Cómo funcionan realmente los EJB de sesión (Stateful Session Beans, SFSB) en Java

(CC) Lilian Wong
Los EJB de sesión (Stateful Session Beans, SFSB) no funcionan como yo pensaba.

(Pensaba que podían llamarse desde un Servlet o desde un EJB Stateless (Stateless Session Bean, SLSB) y que automágicamente diferenciaran entre los navegadores que están accediendo la aplicación Web. Pero no es así.)


Conclusiones
  • El cliente de un SFSB debe guardar la referencia, para poder acceder a la misma instancia.
  • Una referencia a un SLSB no garantiza que se acceda a la misma instancia, pues el servidor típicamente tiene un pool.
  • Si el cliente es la capa web (un Servlet, una JSP), se recomienda guardar la referencia en la sesión web.
  • No es útil ejecutar un SFSB desde un SLSB, pues la instancia que usará será nueva.
  • No se debe inyectar (EJB 3) un SFSB en un SLSB, pues clientes diferentes accederan al SLSB pero estarán accediendo al mismo SFSB.

Referencias

5 de marzo de 2014

Detecta conexiones perdidas (connection leak) a la base de datos en Glassfish 3.1

En ocasiones, una aplicación web deja abiertas conexiones a la base de datos que ya no usará (conexiones perdidas, “connection leak” en inglés). Este error se puede detectar usando las herramientas que tiene Glassfish (lo probé en Glassfish 3.1.2.2). Los pasos son los siguientes.

1. Accede la consulta de Glassfish (normalmente en localhost:4848)

2. Activa la detección de conexiones perdidas en el pool (Resources > JDBC > JDBC Connection Pools > pool > Advanced > Connection Settings > Connection Leak Timeout)



3. Activa el monitor del pool (Monitoring > Action > Configure Monitoring, JDBC Connection Pool > Monitoring Level=HIGH)





4. Accede al monitor del pool (Monitoring Data > View Monitoring Data > Resources)



5. Usa tu aplicación, y detecta cuando el parámetro NumPotentialConnLeak sea mayor a cero.



6. Busca la clase y el número de línea donde ocurrió la pérdida de la conexión (leak) en el stacktrace del hilo de ejecución (thread) en la bitácora del servidor (server > General > View Log Files > Log Viewer Results > Message > details > Complete Message)



7. Arregla el error. :)