Complementando información anteriormente dada, el string e conexion a RAC de Oracle también se define en el caso de SQL Developer, pero como una configuracion avanzada. O sea, se debe establecer de esta forma para llagar al RAC
Como aqui puedes ver en la configuracion estandar no puedes cambiar el string de conexión, por lo que es necesario la avanzada.
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
Dentro del ciclo de vida de una verson de Java existe lo que se llama el ciclo end of life (EOL) que ya llego para Java 6. Esto significa que Java 6 dejará de ser publicado como liberaciones púbvlicas desde febrero del 2013, o sea, cualquier parche que exista para Java si quiere ser descargado tendra un pago de licencia asociado, o adherirse a un progrema de mantención empresarial. Esto debido a que muchos servidores de aplicaciones a un utilizan java 5 y 6. Los que están en operaciones diarias con Java son más sensibles a esta situación, a diferencia de los que utilizan Java para otros fines (educativos o entretenimiento) que deberan moverse a l Java 7.
Dentro de las herramientas utiles para webmasters o optimizadores de sitios web ed Closure Compiler de Goole, que tiene por onjetivo minimizar el Javascript, a parte de correjirlo orientadolo a las buenas prácticas de desarrollo. Es util como herramienta, y aun que ya había mostrado el YUI Compresor, que comprime tanto JS como CSS, Closure Compiler tiene un funcionalidad adicional interesante, la de fusionar dos archivos Javascript evitando la redundancia de codigo, lo que no deja de ser útil.
Luego de descargarlo, y asumiendo que tienes java 1.6 instalado al menos, debes ejecutarlo
c:\opt\java6\bin\java -jar C:\opt\googleClousureCompiler\compiler.jar --js=file.js --js_output_file=file_min.js
Entiendase aqui que tengo una forma de instalar todos los programas que ejecutaré a linea de mando, por eso ambos estan en c:\opt\…algo, además aquí establesco las rutas completas debido a que esta llamada al programa esta hecha en el mismo directorio en donde se encuentra el archivo origen.
Basicamente con esto obtienes un javascript minimizado. Un batch simple para realizar esta tarea sería
c:\opt\java6\bin\java -jar C:\opt\googleClousureCompiler\compiler.jar --js=%1.js --js_output_file=%1_min.js ren %1.js %1.js.old ren %1_min.js %1.js7
Y estando todo bien configurado en el PATH se debiese obtener un resultado optimo. Esta linea de comando, aparte de correr el script central, además corre el re nombramiento de archivos de forma que ademas queda todo respaldado con la opcion de vuelta atras.
En el proceso de desarrollo normal se deben seguir ciertas pautas cuando estas estan estructuradas es mejor, debido a que todos saben a que atenerse.
En muchos casos, en las empresas de desarrollo se usan herramientas de versionamiento, por ejemplo subversion. En estas herramientas existen problematicas no asociadas con la heramienta, sino que asociada a la forma en que se desarrolla. El ejemplo clásico que doy de escritura de código es
if(x){
y = y + 1;
}
y el codigo
if(x)
{
y = y + 1;
}
son equivalentes, pero uno tiene una linea más de codigo que la otra, esto implica que estadisticas relacionadas con ello, pueden producir conclusiones erroneas, en el sentido de, por ejemplo, la productividad de un programador medido en lineas de código.
Para ello en Java, .NET y otros existen herramientas para la verificación de codigo, para Java: Checkstyle, PMD y Findbugs; para .NET: Stlecop, FxCop y Gendarme. Cada una de las cuales explicaré en otros post. Lo que me preocupó hoy es presentar un workflow, o serie de actividades, para proceder al desarrollo de una funcionalidad. Este implica revision de estilo, revision de errores potenciales y revision de programación. Todo ello también va de la mano con la arquitecturas de las aplicaciones aplicadas.
El workflow en cuestion:
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.