Buen día.En este artículo, hablaré sobre la "modernización" en la compañía para la que trabajo de una herramienta como Java Web Start, o más bien, sobre reemplazarla con una solución alternativa de código abierto.Sobre mí
Mi nombre es Ildar y trabajo en una compañía alemana que, como muchas compañías alemanas, usa la pila de tecnología antigua e intenta migrar a una pila más nueva.Problema
Comenzaré con una descripción del problema. Nuestra empresa tiene la parte más importante del sistema, que es una aplicación heredada escrita en Java 6 y parcialmente en Java 8. Fue lanzada en Java 8. Para usar esta aplicación para producción, los usuarios descargan el archivo jnlp del sitio y lo ejecutan en su hogar en computadorasPor lo tanto, la compañía felizmente existió durante mucho tiempo , hasta que Oracle anunció que había dejado de admitir la versión 8 de Java, marcó la tecnología Java Web Start como obsoleta y decidió cortarla comenzando con Java 11. Esto significaba que todavía hay más aplicaciones JWS, de las cuales todavía hay muchas no recibirá actualizaciones de seguridad incluidas. Por supuesto, pocos pueden llegar a un acuerdo con esto. También pensaron que los entusiastas de Karakun decidieron escribir su reemplazo para JWS.En nuestra compañía, hace algún tiempo, comenzaron a reescribir la aplicación usando Spring boot para el backend y React para el frontend, pero el proceso no es rápido y ahora no hay actualizaciones.Busca una solución
Entonces, el equipo de desarrollo se enfrentó a la cuestión de encontrar soluciones alternativas. En general, vale la pena reconocer que hay más de una solución al problema. Inicialmente, los arquitectos seleccionaron dos soluciones GetDown y el mismo OpenWebStart . En el momento de la decisión inicial, la elección recayó en la primera opción, ya que OpenWebStart ni siquiera se lanzó bajo la primera versión (solo había algunos desarrollos y planes).Cada una de las soluciones tenía sus pros y sus contras, pero la compañía decidió no esperar el lanzamiento de OpenWebStart y comenzar a implementar una prueba de concepto basada en GetDown.Después de pasar un par de semanas, uno de los desarrolladores hizo frente a la tarea y nos dimos cuenta de que, en principio, podemos implementar una solución completa que satisfaga nuestros requisitos al pasar un poco más de tiempo.Mientras tanto, llegaron otras tareas urgentes y el equipo de desarrollo se distrajo de la transición de la etapa PoC a la implementación completa del reemplazo de Java Web Start.Plazos
Todos vivieron felices hasta que la gerencia se dio cuenta de que ya era hora de terminar y con el reemplazo de Java Web Start. Hasta este momento, no estaba involucrado en este proyecto, pero aquí también me conectaron.Primero, decidí buscar información sobre soluciones a nuestro problema nuevamente. Así que digamos entrar en la solución desde cero. Por lo tanto, descubrí la existencia de OpenWebStart. Lo probé localmente, encontré algunos problemas (luego nos encontramos con otros también) y los resolví. Como resultado, a todos les gustó la solución. No hace falta decir que a la administración le gustó especialmente porque no tendría que dedicar tiempo al desarrollo, como es el caso de GetDown. Pero al final, pasamos tiempo haciendo que nuestro sistema funcione con OpenWebStart.Información rápida sobre OpenWebStart
OpenWebStart se basa en otra implementación de Java Web Start: IcedTea-Web y la especificación JNLP JSR-56 . Al momento de escribir, el proyecto existe en la versión 1.1.4 y planea implementar las características principales de Java Web Start (el progreso se puede observar aquí ).No veo el punto de enumerar todas las configuraciones posibles, puede llevar mucho tiempo.Estos son solo algunos de ellos:- gestión de caché (tamaño, ubicación ...),
- configuración de seguridad (que permite a los usuarios ejecutar una aplicación no firmada por certificados, mostrar o no ventanas emergentes de advertencia ...),
- agregar direcciones de servidor a la lista blanca,
- configuración de depuración remota,
- gestión de certificados de seguridad
- Control de versiones JRE / JDK,
- otro
Características del uso de OpenWebStart y los problemas que encontramos
Instalar OpenWebStart
Instalar OpenWebStart es bastante simple. Es suficiente descargar el archivo de instalación de su plataforma en el sitio web y seguir las instrucciones del instalador.Pero esto es mala suerte. En nuestro caso, los usuarios son aproximadamente 10,000 clientes, para cada uno de los cuales el servicio de soporte de nuestra empresa debe instalar esta herramienta. La solución se encontró bastante rápido: la llamada instalación en segundo plano está disponible.Debe cargar el archivo de instalación en cada una de las computadoras y ejecutar un comando especial (y para esto la compañía ya tiene una herramienta):OpenWebStart_windows_Setup.exe -q -varfile response.varfile
, donde response.varfile es un archivo con algunas configuraciones que el instalador puede configurar de antemano. Por ejemplo, la carpeta en la que instalar OpenWebStart y algunos otros.Bueno, nos enfrentamos a este problema. Además, sería necesario que todos los clientes instalen de alguna manera una versión específica de AdoptOpenJDK y los vinculen a OpenWebStart, que se realiza fácilmente a través de la interfaz de usuario, pero este no es nuestro caso.
Encontramos en la configuración que puede especificar la URL desde la cual OpenWebStart tomará el archivo de configuración, en el que puede especificar la URL al JRE que necesitamos. Y la URL en sí con el archivo de configuración se puede especificar en el archivo response.var mencionado anteriormente (así de complicado es).El archivo de configuración JSON en sí con diferentes versiones de JRE es el siguiente .En la configuración, también puede especificar la versión y el proveedor del JRE, en caso de que se especifiquen varios JRE en el archivo JSON. Indicamos solo uno y subimos el archivo JSON y el archivo con el JRE que necesitamos en el bucket de Amazon S3.Después de probar, descubrimos que con la versión de JRE que descargamos, la aplicación no se inicia ... Resultó que nuestro Java tiene una estructura ligeramente diferente en el archivo. Creamos un script por lotes que reconstruyó la estructura del archivo JRE."Bueno, ahora todo funcionará bien", pensamos.Cuando inicia la aplicación por primera vez, el JRE se carga automáticamente, lo que se utilizará en el futuro. Pero, estábamos esperando la próxima sorpresa.La desgracia nunca viene sola
Pero como suele suceder, no estábamos limitados a un problema.Nuestra aplicación tiene, digamos, una característica. En realidad hay dos de ellos. Una aplicación (un archivo jnlp) inicia una segunda aplicación (segundo jnlp). Y en este caso, la segunda aplicación no se inició. En los registros, puede ver que las aplicaciones están estancadas en el punto muerto. A partir del seguimiento oculto, quedó claro que la razón es el mecanismo de registro interno OpenWebStart.El problema se resolvió deshabilitando el registro interno de OpenWebStart. Los registros de nuestras aplicaciones, por supuesto, permanecieron encendidos.
Esta configuración también se desactivó en el archivo response.varfile, que se utiliza durante la instalación en segundo plano.Y ahora, después de superar estos y algunos otros obstáculos (no tengo que mencionarlos a todos), logramos lanzar nuestra aplicación, que actualmente se está sometiendo a pruebas antes de ser lanzada al producto. Como probamos, la versión de OpenWebStart se actualizó de 1.1.1 a 1.1.4. De los cambios notables se agregó la capacidad de debutar de forma remota.
Quizás mi artículo sea útil para alguien en un trabajo tan difícil como el soporte para aplicaciones heredadas. Si tiene preguntas, pregunte, intentaré responder.PD: todas las imágenes se toman del sitio web oficial de OpenWebStart .