![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
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...
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:
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 ):
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.
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á.
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 .
A comunidade Spring Boot fornece recomendações sobre como executar o aplicativo Spring Boot no ambiente EE + Documentação oficial
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:
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>
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:
domain-dir/autodeploy
asadmin
- comando de implantaçãojava -jar
: spring-boot-maven-plugin cria dois artefatos - war
e war.original
. O war
simples inclui lib-provided
, o original
nã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>
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:
@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); } }
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