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 em um servidor de aplicativos quando ele pode ser executado de forma independente? Afinal, esse é um dos recursos de destaque do Spring Boot. Spring Boot E então, pode haver várias razões para isso: 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. 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 Diferentes experiências e competências na equipe Experimentos e testes de hipóteses Java 8 O Java 8 foi lançado em 18 de março de 2014 e trouxe que usamos até hoje. recursos importantes 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, foram lançadas até hoje ( ): três versões LTS 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 , 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. estudo conduzido pela New Relic 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 , 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. site da Oracle Basta colocar o arquivo de distribuição em algum lugar da sua máquina, navegar até a pasta e executar o seguinte comando: bin ./asadmin start-domain --verbose Aguarde um pouco e tente abrir , 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. http://localhost:4848/ 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. em 2021 e requer o Java 8 como versão mínima, diferente . O Spring Boot 2 foi lançado 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 deles, 2.7.18 se tornou a versão mais recente de suporte Spring Boot 2.x e consequentemente Java 8 e Java 11: o blog 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 sobre como executar o aplicativo Spring Boot no ambiente EE + fornece recomendações Documentação oficial pom.xml O mínimo e suficiente para construir e executar o aplicativo será semelhante ao seguinte: pom.xml <?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 dentro do artefato resultante. Agora você tem pelo menos três opções para executar o artefato resultante: lib-provided 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 - comando asadmin de implantação Execute usando : dois artefatos - e . O simples inclui , o não. java -jar spring-boot-maven-plugin cria war war.original war lib-provided original 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 e a anotaria com a anotação . main @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: Herdar classe Application de SpringBootServletInitializer 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 Não tenha medo de usar tecnologias mais antigas Mantenha a curiosidade e continue desenvolvendo suas habilidades Boa sorte GitHub LinkedIn
