Primero - Packaging (Empaquetado)
Cuando terminamos de desarrollar un applet, y debemos empezar a probarlo dentro del contexto de la aplicación de negocios, se hace necesario empaquetarlo en un archivo JAR (no entraré en detalles de porqué, dado que hay mucha información al respecto). Lo que ocurre normalmente, es que en nuestro ambiente de desarrollo, el applet funciona perfectamente, pero cuando lo empaquetamos y lo colocamos en un sitio, comienzan los problemas. Uno de los errores mas comunes es que en el empaquetado nos olvidemos de hacer referencia a las librerías externas utilizadas en el desarrollo y que se necesitan en tiempo de runtime.
Para solucionar esto, y evitar que el JAR generado sea muy grande, se pueden colocar las librerías mencionadas (JAR de éstas) en una ubicación específica en el mismo sitio, y hacer referencia a ellas en nuestro applet a través del archivo MANIFEST.MF, incluyendo la ruta en la propiedad Class-Path. Por ejemplo el archivo quedaría:
Manifest-Version: 1.0
Main-Class: MiEspacioDeNombres.MiClase.class
Class-Path: lib_externa1.jar lib_externa2.jar lib_externa3.jar
Algunos detalles importantes son que la separación de los JAR debe ser con espacios, la lista NO debe ser en una sola línea si hay varios JAR (el largo de cada fila no debería superar los 80 caracteres, y cuando pasamos a la fila de abajo, debemos dejar un espacio inicial para que sea reconocida. Un ejemplo completo se puede descargar de aquí. En este ejemplo las librerías se deberían ubicar en el mismo directorio del JAR de nuestro applet.
Segundo - Permisos de Ejecución
Si el applet no accede a ningún recurso local de la máquina cliente donde
ejecuta, no habrá problemas con los permisos de ejecución, de otra forma, es necesario agregar esos permisos en el archivo java.policy, ubicado en el directorio C:\Archivos de programa\Java\jre<version>\lib\security (obviamente si la distribución del sistema operativo es en inglés será C:\Programs Files). Allí se deben agregar los permisos necesarios de acuerdo a nuestras necesidades. En ésta página encontrarán detalles de suma utilidad para este tema. Por supuesto que una salida rápida es agregar permisos para todo de la forma:
permission java.security.AllPermission;
Esto soluciona rápidamente el problema de funcionamiento, pero abre la puerta a potenciales ataques malintencionados. Mi recomendación es que se tomen el trabajo de ir probando (si al menos no tienen claro que permisos necesitan) y habilitando solo lo necesario. Para este trabajo es útil el siguiente punto de testing y debug.
Tercero - Testing y Debug
Cuando desarrollamos un applet utilizamos una versión específica de Java. Otro problema común es que no sabemos cual es la versión instalada en la máquina cliente que lo ejecutará. Para evitar malos resultados, es necesario entonces probar el applet con diferentes versiones JVM.
Para esto es muy útil:
- Habilitar la consola de Java en tiempos de ejecución
- Ir cambiando la versión de java, con la que el navegador utilizado en las pruebas, ejecutará el applet.
Para lo primero se debe ingresar a Panel de Control > Java > Avanzado y habilitar la consola de la forma: 
|
Para lo segundo, en Panel de Control > Java > Java, se habilita o deshabilita la versión que deseamos utilizar con el navegador, de la forma:
 Nota: Es necesario cerrar el navegador cada prueba que hagamos para que no use caché. |
Luego, cuando ejecutamos el applet desde el navegador, llamando a la página donde se encuentra, Java abre automáticamente la Consola y muestra allí cualquier excepción que se produzca, tanto por falta de permisos como por fallas del funcionamiento propio del applet (faltas de librerías externas, etc.).
 |
So far, so good!
Images by Tinypic
0 comentarios:
Publicar un comentario