De volta ao futuro: executando o Spring Boot 2 no GlassFish 4 usando Java 8

Negação, Raiva, Negociação, Depressão…

Todo desenvolvedor sonha em trabalhar com tecnologias modernas e se manter atualizado. Na verdade, é quase impossível construir uma estratégia de contratação forte em torno de tecnologias ultrapassadas, obsoletas e muitas vezes ineficazes e até natimortas.

No entanto, a vida é complexa e nem tudo depende sempre dos nossos desejos.

Você pode receber uma promoção e ser transferido para um projeto em que as tecnologias não mudaram ou foram atualizadas em anos. Ou você pode conseguir um emprego na empresa dos seus sonhos, onde a pilha de tecnologia atual não lhe interessa particularmente no momento. Talvez você tenha acabado de se formar na universidade e esteja ansioso para ganhar sua primeira experiência de trabalho, ou talvez tenha sido demitido do seu emprego anterior e precise encontrar algo rapidamente para evitar dificuldades financeiras.

Há também outro cenário: durante a entrevista, você é informado de que começará a trabalhar com a pilha atual, mas terá muitas oportunidades de fazer mudanças no futuro — talvez, possivelmente, mas...

Aceitação…

Mas sejamos honestos, isso é tudo apenas filosofia. Eu concordo, e proponho que analisemos um caso real que você pode encontrar em sua desafiadora carreira.

Para todos os fãs da pilha JVM, especialmente aqueles que amam o Spring Framework, isto é para vocês, por favor, continuem lendo.

Aliás, por que você precisaria implantar um aplicativo Spring Boot em um servidor de aplicativos quando ele pode ser executado de forma independente? Afinal, esse é um dos recursos de destaque do Spring Boot.

E então, pode haver várias razões para isso:

1. Você pode já ter a infraestrutura configurada para implementar aplicativos no GlassFish ou em outro EE Application Server. Neste caso, o EE Application Server está instalado, configurado e totalmente suportado. Mesmo que o aplicativo possa ser executado de forma independente, como acontece com o Spring Boot, você ainda precisará preparar e manter a infraestrutura para implementação e tempo de execução.
2. Você sabe que depois de um tempo você começará a abandonar o servidor de aplicação e portanto começará a utilizar antecipadamente a tecnologia que você utilizará no futuro com a possibilidade de utilizá-la no ambiente atual
3. Diferentes experiências e competências na equipe
4. Experimentos e testes de hipóteses

Java 8

O Java 8 foi lançado em 18 de março de 2014 e trouxe recursos importantes que usamos até hoje.

Não preciso ir muito longe para dar exemplos, aqui estão alguns deles:

• Expressões Lambda

• API de fluxo

• Classe opcional

• O pacote java.time (API de data e hora)

• etc etc

  
  

Desde então, três versões LTS foram lançadas até hoje ( 19/08/2024 ):

• Java SE 11(55) - 25 de setembro de 2018
• Java SE 17(61) - 14 de setembro de 2021
• Java SE 21(65) - 19 de setembro de 2023

De acordo com um estudo conduzido pela New Relic , o Java 8 ainda é usado em 28,8% dos projetos atuais, o que, como você concordará, não é insignificante. Embora sua participação esteja diminuindo gradualmente ano a ano, certamente é muito cedo para descartar essa tecnologia completamente.

GlassFish 4.1.2

De acordo com o site do Projeto Eclipse dedicado ao Eclipse GlassFish :

Eclipse GlassFish® é um servidor de aplicação completo que implementa a especificação Jakarta EE. O GlassFish inclui implementações de todas as APIs Jakarta EE obrigatórias e opcionais, e passa todos os TCKs Jakarta EE. O GlassFish também inclui um console de administração completo, suporte a clustering e outras ferramentas e recursos focados em desenvolvimento e produção.

Infelizmente, não é possível baixar deste site versões mais novas que 5.1.0, mas como decidimos usar a versão abaixo da quinta, teremos que ir ao site da Oracle , onde você pode encontrar várias versões anteriores deste produto na seção Downloads. Mas tenha cuidado com a licença e não use nada desta pasta fora do seu sandbox.

Basta colocar o arquivo de distribuição em algum lugar da sua máquina, navegar até a pasta bin e executar o seguinte comando:

 ./asadmin start-domain --verbose

Aguarde um pouco e tente abrir http://localhost:4848/ , o Admin Console deve estar disponível por padrão e não deve pedir nenhum tipo de credencial. No painel esquerdo, você encontrará a aba Applications, se clicar nela, terá acesso a um menu com o qual você pode implantar, desimplantar, habilitar e desabilitar aplicativos.

Isso é tudo o que você precisa saber sobre o GlassFish no momento para tentar implantar seu aplicativo lá.

Bota de mola 2

Provavelmente é muito difícil encontrar uma pessoa no mundo do desenvolvimento web que não tenha ouvido falar dessa estrutura popular pelo menos uma vez.

O Spring Boot 2 foi lançado em 2021 e requer o Java 8 como versão mínima, diferente da versão 3, que requer o Java 17 como versão mínima .

Para poder usar os recursos mais recentes, patches de segurança e algumas otimizações, precisamos encontrar a versão mais recente que suporte o Java 8.

E aqui está, 2.7.18, de acordo com o blog deles, 2.7.18 se tornou a versão mais recente de suporte Spring Boot 2.x e consequentemente Java 8 e Java 11:

Após 5,5 anos e 121 lançamentos, 2.7.18 marca o fim do suporte de código aberto para Spring Boot 2.x. Atualize para Spring Boot 3 o mais rápido possível. Se você ainda não estiver pronto para atualizar, o suporte comercial para Spring Boot 2.7.x está disponível .

Começando a usá-los juntos

Pré-requisitos:

• Java 8
• GlassFish 4.1.2
• Spring Boot 2.7.18
• Especialista

A comunidade Spring Boot fornece recomendações sobre como executar o aplicativo Spring Boot no ambiente EE + Documentação oficial

pom.xml

O pom.xml mínimo e suficiente para construir e executar o aplicativo será semelhante ao seguinte:

 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <groupId>io.github.isharipov</groupId> <artifactId>sb2-to-gf4</artifactId> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <exclusions> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion> </exclusions> <scope>provided</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>

Aqui você precisa prestar atenção em duas coisas:

1. Estou empacotando o aplicativo como um arquivo war para deixar claro para o servidor de aplicativos que estou implantando um aplicativo da web

   
   

    <packaging>war</packaging>

2. Estou excluindo o Tomcat incorporado adicionando a dependência spring-boot-starter-tomcat excluindo duas dependências internas e adicionando o escopo fornecido

   
   

    <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <exclusions> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion> </exclusions> <scope>provided</scope> </dependency>

Essa abordagem permite que você inclua o Tomcat e o torne disponível apenas para o tempo de execução do Spring Boot, permitindo que você execute o aplicativo independentemente do servidor de aplicativos. Essa separação é importante. O Spring coloca essa dependência em uma pasta separada chamada lib-provided dentro do artefato resultante. Agora você tem pelo menos três opções para executar o artefato resultante:

• Implantar no GlassFish - basicamente, há três maneiras de implantar um aplicativo :
  • GUI de administração do GlassFish
  • Copie seu arquivo compactado para o diretório autodeploy em domain-dir/autodeploy
  • API asadmin - comando de implantação
• Execute usando java -jar : spring-boot-maven-plugin cria dois artefatos - war e war.original . O war simples inclui lib-provided , o original não.
• Inicie o aplicativo em seu IDE favorito - para o IntelliJ IDEA Community Edition, você precisa adicionar a seguinte opção em Configuração de execução/depuração

Excluir as seguintes dependências nos permite reduzir o tamanho do artefato resultante:

 <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion>

Classe de aplicação

Para executar um aplicativo Spring Boot em um servidor de aplicativos, você precisará fazer duas modificações na classe principal do aplicativo.

Normalmente, para configurar um aplicativo web simples, você criaria uma classe pública com um método main e a anotaria com a anotação @SpringBootApplication .

 @SpringBootApplication public class Application { private static final Logger LOGGER = LoggerFactory.getLogger(Application.class); public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

Então, como mencionei acima, duas alterações:

1. Herdar classe Application de SpringBootServletInitializer
2. Substituir método protegido SpringApplicationBuilder configure(SpringApplicationBuilder builder)

 @SpringBootApplication public class Application extends SpringBootServletInitializer { private static final Logger LOGGER = LoggerFactory.getLogger(Application.class); public static void main(String[] args) { LOGGER.debug("From main"); SpringApplication.run(Application.class, args); } @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { LOGGER.debug("From configure"); return application.sources(Application.class); } }

Descritor de Implantação

E por último, mas não menos importante, você precisa adicionar o Deployment Descriptor

Então, na pasta principal → src → webapp → WEB-INF você precisa colocar o seguinte arquivo - glassfish-web.xml :

 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd"> <glassfish-web-app> <class-loader delegate="false"/> <session-config> <session-manager/> </session-config> <jsp-config/> </glassfish-web-app>

Leia mais sobre o Deployment Descriptor

Leia mais sobre Delegação do Class Loader

Encerrando

1. Não tenha medo de usar tecnologias mais antigas
2. Mantenha a curiosidade e continue desenvolvendo suas habilidades
3. Boa sorte

GitHub

LinkedIn