…el día a día…

La verdad sea dicha, carecemos de recursos ilimitados para poder probar aplicaciones en ambientes ni siquiera similares a los que poseen nuestros clientes, esto solo existe para productos más consolidados. Por lo mismo hay que buscar las estrategías necesarias para que en un servidor quepan multiples instancias y así rentabilizar más los recursos.

Cuando se habla de multiples instancias estamos hablando de que JBoss se puede configurar para correr en más de un puerto, una explicación bastante buena esta en un blog de una compañía argentina Avant Garden Technologies. Con este artículo podrás tener multiples instancias de JBoss, aun cuando el único reparo que debo hacerle es que el cambiar por «fuerza bruta» los puertos Sí funciona, yo lo pude hacer cuando aun no entendía bien como funcionaba el tema de las instancias, ellos indican lo contrario. Aun así ellos entregan con argumentos conceptuales y practicos para poder establecer más de una instancia.

Pero llegue al punto en donde tengo una aplicacion que debo mantener multiples versiones. Aun cuando tenga multiples instancias algunas configuraciones se solapan. Es posible mantener en multiples instancias multiples datasources debido a que esta dentro de la carpeta deploy. Pero muchas veces requieres leer un archivo especifico, que debes colocar en una ruta externa a JBoss, para lo cual te vales del CLASSPATH de Java… y ahí existe un problema cuando deseas ejecutar distintas versiones de la aplicación en el mismo servidor, no importando que tengas multiples instancias el CLASSPATH para JBoss es único, para todas sus instancias, por lo que se te provocan algunos problemas.

La aplicación lee un archivo de propiedades x.properties, este archivo esta ubicado en alguna parte dentro del CLASSPATH si tu deseas modificar una llave de este archivo la modificarás para ambas versiones de la aplicación, y eso no es lo que ando buscando, sino que cada aplicación lea su propio properties. Inicialmente hice que la version de producción leyera x.properties y la version de qa y.properties, pero nos paso la cuenta el control de versiones, en donde estos archivos son distintos por lo que las nuevas llaves creadas en y.properties no eran traspasadas a x.properties siempre, con los inherentes problemas de ejecución.

Ahora bien, la exigencia de que el properties este fuera de JBoss (el servidor de aplicaciones) es un petición del cliente, es más solucionable si esto estuviese dentro, debido a que cada instancia vería su ambito solamente.

Entonces como habían dos CLASSPATH excluyentes lo que hice fue copiar la carpeta JBoss completa, y con las multiples instancias ya aplicadas fue hacer un

/usr/local/jboss/bin/run.sh -b 0.0.0.0 -c default 

y un

/usr/local/jbossqa/bin/run.sh -b 0.0.0.0 -c qa

Y así tuve dos instancias de JBoss con la misma aplicación y distinta versión, apuntando a distintos CLASSPATH

Tengo una pagina JSP encargada del proceso de «download» para cualquier archivo. Esta había sido probada en varios sistemas operativos hasta que me topé con Solaris. En Solaris uno no puede leer un archivo que este fuera de la ruta del servidor de aplicaciones, envía error y no lee el archivo (en otros sistemas operativos no sucede). Para poder hacerlo no hay que abrirlo como File sino como URL, pero para abrirlo como URL, hay que antepornerle el protocolo ‘file://’, siendo esto compatible con todos los sistemas operativos.

String file = "file://" + request.getParameter("file");
	
OutputStream output = response.getOutputStream();
InputStream in = null;
try {
    URL url = new URL(file);
    in = url.openStream();
    byte[  ] buf = new byte[4 * 1024]; 
    int bytesRead;
    while ((bytesRead = in.read(buf)) != -1) {
        output.write(buf, 0, bytesRead);
    }
} finally {
    if (in != null) in.close();
}

La verdad es que independientemente del sistema operativo esto debió ser siempre así, sólo que muchas veces uno se queda con lo primero que le resulta.