![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Todo desarrollador sueña con trabajar con tecnologías modernas y mantenerse actualizado. De hecho, es casi imposible desarrollar una estrategia de contratación sólida en torno a tecnologías obsoletas, desactualizadas y, a menudo, ineficaces e incluso fallidas.
Sin embargo, la vida es compleja y no todo depende siempre de nuestros deseos.
Es posible que le ofrezcan un ascenso y lo transfieran a un proyecto en el que las tecnologías no hayan cambiado ni se hayan actualizado en años. O puede que consiga un trabajo en la empresa de sus sueños, donde la tecnología actual no le interesa particularmente en este momento. Tal vez acaba de graduarse de la universidad y está ansioso por obtener su primera experiencia laboral, o tal vez lo despidieron de su trabajo anterior y necesita encontrar algo rápidamente para evitar dificultades económicas.
También hay otro escenario: durante la entrevista, te dicen que comenzarás a trabajar con la pila actual, pero que tendrás muchas oportunidades de hacer cambios en el futuro, tal vez, posiblemente, pero...
Pero seamos sinceros, todo esto es pura filosofía. Estoy de acuerdo y te propongo que analicemos un caso real que podrías encontrarte en tu desafiante trayectoria profesional.
Para todos los fanáticos de la pila JVM, especialmente aquellos que aman Spring Framework, esto es para ustedes, por favor, sigan leyendo.
Por cierto, ¿por qué necesitarías implementar una aplicación Spring Boot en un servidor de aplicaciones cuando puede ejecutarse de forma independiente? Después de todo, esa es una de las características más destacadas de Spring Boot.
Y entonces, puede haber varias razones para esto:
Java 8 se lanzó el 18 de marzo de 2014 y trajo consigo características importantes que usamos hasta el día de hoy.
No necesito ir muy lejos para encontrar ejemplos, aquí van algunos de ellos:
Expresiones Lambda
API de transmisión
Clase opcional
El paquete java.time (API de fecha y hora)
etc etc
Desde entonces, se han lanzado tres versiones LTS hasta el día de hoy ( 19/08/2024 ):
Según un estudio realizado por New Relic , Java 8 todavía se utiliza en el 28,8% de los proyectos actuales, lo que, como estará de acuerdo, no es una cifra despreciable. Aunque su porcentaje va disminuyendo gradualmente año tras año, sin duda es demasiado pronto para descartar por completo esta tecnología.
Según el sitio web del Proyecto Eclipse dedicado a Eclipse GlassFish :
Eclipse GlassFish® es un servidor de aplicaciones completo que implementa la especificación Jakarta EE. GlassFish incluye implementaciones de todas las API de Jakarta EE obligatorias y opcionales, y aprueba todos los TCK de Jakarta EE. GlassFish también incluye una consola de administración completa, compatibilidad con clústeres y otras herramientas y funciones enfocadas en la producción y el desarrollo.
Lamentablemente, no es posible descargar desde esta web versiones anteriores a la 5.1.0, pero como hemos decidido utilizar la versión anterior a la quinta, tendremos que acudir a la web de Oracle , donde en la sección Descargas se pueden encontrar varias versiones anteriores de este producto. Pero ten cuidado con la licencia y no utilices nada de esta carpeta fuera de tu sandbox.
Simplemente coloque el archivo de distribución en algún lugar de su máquina, navegue hasta la carpeta bin
y ejecute el siguiente comando:
./asadmin start-domain --verbose
Espera un momento e intenta abrir http://localhost:4848/ , la consola de administración debería estar disponible por defecto y no debería pedirte ningún tipo de credenciales. En el panel izquierdo encontrarás la pestaña Aplicaciones, si haces clic en ella tendrás acceso a un menú con el que podrás desplegar, anular despliegue, habilitar y deshabilitar aplicaciones.
Eso es todo lo que necesita saber sobre GlassFish en este momento para intentar implementar su aplicación allí.
Probablemente sea bastante difícil encontrar una persona en el mundo del desarrollo web que no haya oído hablar de este popular framework al menos una vez.
Spring Boot 2 se lanzó en 2021 y requiere Java 8 como versión mínima, a diferencia de la versión 3 que requiere Java 17 como versión mínima .
Para poder utilizar las últimas funciones, parches de seguridad y algunas optimizaciones, debemos encontrar la última versión que admita Java 8.
Y aquí está, 2.7.18, según su blog , 2.7.18 se convirtió en la última versión compatible con Spring Boot 2.x y, en consecuencia, Java 8 y Java 11:
Después de 5,5 años y 121 lanzamientos, la versión 2.7.18 marca el fin del soporte de código abierto para Spring Boot 2.x. Actualice a Spring Boot 3 lo antes posible. Si aún no está listo para actualizar, hay soporte comercial disponible para Spring Boot 2.7.x.
La comunidad Spring Boot ofrece recomendaciones sobre cómo ejecutar la aplicación Spring Boot en el entorno EE + Documentación oficial
El pom.xml mínimo y suficiente para crear y ejecutar la aplicación se verá así:
<?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>
Aquí hay que prestar atención a dos cosas:
Estoy empaquetando la aplicación como un archivo war para dejarle claro al servidor de aplicaciones que estoy implementando una aplicación web.
<packaging>war</packaging>
Estoy excluyendo Tomcat integrado agregando la dependencia spring-boot-starter-tomcat excluyendo dos dependencias internas y agregando el alcance proporcionado
<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>
Este enfoque le permite incluir Tomcat y hacerlo disponible solo para el entorno de ejecución de Spring Boot, lo que le permite ejecutar la aplicación independientemente del servidor de aplicaciones. Esta separación es importante. Spring coloca esta dependencia en una carpeta separada llamada lib-provided dentro del artefacto resultante. Ahora tiene al menos tres opciones para ejecutar el artefacto resultante:
domain-dir/autodeploy
asadmin
: comando de implementaciónjava -jar
: spring-boot-maven-plugin crea dos artefactos: war
y war.original
. El war
simple incluye lib-provided
, el original
no.Excluir las siguientes dependencias nos permite reducir el tamaño del artefacto 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 ejecutar una aplicación Spring Boot en un servidor de aplicaciones, deberá realizar dos modificaciones en la clase de aplicación principal.
Normalmente, para configurar una aplicación web simple, debes crear una clase pública con un método main
y anotarla con la anotación @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); } }
Entonces, como mencioné anteriormente, dos enmiendas:
@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); } }
Y por último, pero no menos importante, debes agregar el Descriptor de implementación.
Entonces, en la carpeta principal → src → webapp → WEB-INF debes colocar el siguiente archivo: 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>
Obtenga más información sobre el descriptor de implementación
Obtenga más información sobre la delegación del cargador de clases