Dia bom.Neste artigo, falarei sobre a "modernização" na empresa em que trabalho, de uma ferramenta como Java Web Start, ou melhor, sobre substituí-la por uma solução alternativa de código-fonte.Sobre mim
Meu nome é Ildar e trabalho para uma empresa alemã que, como muitas empresas alemãs, usa a pilha de tecnologia antiga e tenta migrar para uma pilha mais nova.Problema
Vou começar com uma descrição do problema. Nossa empresa possui a parte mais importante do sistema, que é um aplicativo herdado escrito em java 6 e parcialmente em java 8. Foi lançado em java 8. Para usar esse aplicativo para produção, os usuários baixam o arquivo jnlp do site e o executam em casa em computadores.Assim, a empresa feliz existido por um longo tempo até que a Oracle anunciou o fim das ajudas para a versão 8 de java, não marcou tecnologia Java Web Start como obsoleto, e decidiu cortá-la para fora de java 11. Isso significava que ainda existem aplicações mais JWS, dos quais há muitos não receberá, incluindo atualizações de segurança. Obviamente, poucos podem aceitar isso. Entusiastas de Karakun também decidiram escrever seu substituto para o JWS.Em nossa empresa, há algum tempo, eles começaram a reescrever o aplicativo usando a inicialização do Spring para o back-end e o React para o front-end, mas o processo não é rápido e não há atualizações agora.Procure uma solução
Portanto, a equipe de desenvolvimento enfrentou a questão de encontrar soluções alternativas. Em geral, vale a pena reconhecer que há mais de uma solução para o problema. Inicialmente, os arquitetos selecionaram duas soluções GetDown e o mesmo OpenWebStart . No momento da decisão inicial, a escolha caiu na primeira opção, pois o OpenWebStart nem sequer foi lançado na primeira versão (havia apenas alguns desenvolvimentos e planos).Cada uma das soluções tinha seus prós e contras, mas a empresa decidiu não esperar pelo lançamento do OpenWebStart e começar a implementar a prova de conceito com base no GetDown.Depois de passar algumas semanas, um dos desenvolvedores lidou com a tarefa e percebemos que, em princípio, podemos implementar uma solução completa que atenda aos nossos requisitos, gastando um pouco mais de tempo.Enquanto isso, outras tarefas urgentes chegaram e a equipe de desenvolvimento se distraiu da transição do estágio PoC para a implementação completa da substituição do Java Web Start.Prazos
Todos viveram felizes até que a gerência percebeu que já era hora de terminar e com a substituição do Java Web Start. Até o momento, eu não estava envolvido nesse projeto, mas aqui eles me conectaram também.Primeiro, decidi procurar informações sobre soluções para o nosso problema novamente. Então, digamos, entre na solução do zero. Assim, descobri a existência do OpenWebStart. Eu testei localmente, tive alguns problemas (depois também encontramos outros) e os resolvi. Como resultado, todos gostaram da solução. Desnecessário dizer que a gerência gostou especialmente porque não precisaria gastar tempo em desenvolvimento, como é o caso do GetDown. Mas, no final, gastamos tempo fazendo nosso sistema funcionar com o OpenWebStart.Informações rápidas sobre o OpenWebStart
O OpenWebStart é baseado em outra implementação do Java Web Start - IcedTea-Web e na especificação JNLP JSR-56 . No momento da redação deste artigo, o projeto existe na versão 1.1.4 e planeja implementar os principais recursos do Java Web Start (o progresso pode ser observado aqui ).Não vejo o ponto de listar todas as configurações possíveis; pode levar muito tempo.Aqui estão apenas alguns deles:- gerenciamento de cache (tamanho, localização ...),
- configurações de segurança (permitindo que os usuários executem um aplicativo não assinado por certificados, exibindo ou não pop-ups de aviso ...),
- adicione endereços de servidor à lista branca,
- configurações de depuração remota,
- gerenciamento de certificado de segurança
- Controle de versão JRE / JDK,
- de outros
Recursos do uso do OpenWebStart e os problemas que encontramos
Instale o OpenWebStart
Instalar o OpenWebStart é bastante simples. Basta baixar o arquivo de instalação da sua plataforma no site e seguir as instruções do instalador.Mas isso é má sorte. No nosso caso, os usuários são cerca de 10.000 clientes, para cada um dos quais o serviço de suporte de nossa empresa deve instalar essa ferramenta. A solução foi encontrada rapidamente: a chamada instalação em segundo plano está disponível.Você precisa fazer o upload do arquivo de instalação em cada um dos computadores e executar um comando especial (e para isso a empresa já possui uma ferramenta):OpenWebStart_windows_Setup.exe -q -varfile response.varfile
, em que response.varfile é um arquivo com algumas configurações que podem ser definidas com antecedência pelo instalador. Por exemplo, a pasta na qual instalar o OpenWebStart e algumas outras.Bem, nós lidamos com este problema. Além disso, seria necessário que todos os clientes instalassem, de alguma forma, uma versão específica do AdoptOpenJDK e os vinculassem ao OpenWebStart, o que é feito facilmente através da interface do usuário, mas esse não é o nosso caso.
Encontramos nas configurações que você pode especificar o URL do qual o OpenWebStart utilizará o arquivo de configurações, no qual você pode especificar o URL para o JRE de que precisamos. E a própria URL com o arquivo de configurações pode ser especificada no arquivo response.varf mencionado acima (é assim que é complicado).O arquivo de configurações JSON em si com diferentes versões do JRE é o seguinte .Nas configurações, você também pode especificar a versão e o fornecedor do JRE, caso vários JREs sejam especificados no arquivo JSON. Indicamos apenas um e carregamos o arquivo JSON e o archive com o JRE necessário no bucket do Amazon S3.Após o teste, descobrimos que, com a versão do JRE que baixamos, o aplicativo não inicia ... Acontece que nosso Java possui uma estrutura ligeiramente diferente no arquivo morto. Criamos um script em lote que reconstruiu a estrutura do arquivo JRE."Bem, agora tudo vai funcionar bem", pensamos.Quando você inicia o aplicativo, o JRE é carregado automaticamente, o que é usado no futuro. Mas estávamos esperando a próxima surpresa.O infortúnio nunca vem sozinho
Mas, como geralmente acontece, não estávamos limitados a um problema.Nossa aplicação possui, digamos, um recurso. Na verdade, existem dois deles. Um aplicativo (um arquivo jnlp) inicia um segundo aplicativo (segundo jnlp). E, neste caso, o segundo aplicativo não foi iniciado. Nos logs, você pode ver que os aplicativos estão presos no impasse. A partir do rastreamento furtivo, ficou claro que o motivo é o mecanismo de log interno do OpenWebStart.O problema foi resolvido desativando o log interno do OpenWebStart. Os logs de nossos aplicativos, é claro, permaneceram ativos.
Essas configurações também foram desativadas no arquivo response.varfile, usado durante a instalação em segundo plano.E agora, depois de superar esses e alguns outros obstáculos (não preciso mencionar todos já), conseguimos lançar nosso aplicativo, que está atualmente em teste antes de ser liberado para o prod. Como testamos, a versão do OpenWebStart foi atualizada de 1.1.1 para 1.1.4. Das mudanças notáveis foi adicionada a capacidade de estrear remotamente.
Talvez meu artigo seja útil para alguém em um trabalho tão difícil como suporte para aplicativos herdados. Se você tiver perguntas - pergunte, tentarei responder.PS todas as imagens são tiradas do site oficial do OpenWebStart .