Aplicación de primavera independiente de Springboot
Aplicación de resorte independiente
Como se menciona en el título, springboot ayuda a implementar una aplicación de resorte y enfatiza de forma independiente la posición central del resorte. ¿Por qué lo dices? ¿La primavera no usó la primavera en los proyectos antes de que apareciera springboot? Bastantes, pero en proyectos anteriores, ya sea un proyecto web o no web, Spring solo asume el papel de vinculación, algunos extranjeros también lo llaman en broma "pegamento". De hecho, en el sistema Java EE, los conceptos de IOC y DI se propusieron antes de la primavera. El nacimiento de la primavera es en realidad una rueda repetitiva. Después de luchar (luchar contra el padre), es importante, pero no absoluto. Con la aparición de las botas de resorte, la primavera se alejó de su posición incómoda y marcó el comienzo de una nueva primavera. Por ejemplo: en el pasado, los proyectos web utilizaban el contenedor web como núcleo, y el registro y la inicialización del contenedor de primavera se llevaban a cabo durante el inicio del contenedor web. El proyecto de arranque de primavera actual se basa en la primavera y la incrustación se inicializa durante el proceso de inicio de primavera Contenedor web.
FATJÓ
Es muy simple iniciar la aplicación Springboot. Una vez completado el empaquetado, use java -jar xxx.jar para iniciarlo. Dando la vuelta, parece que has vuelto al punto de partida, ¿verdad? Una llamada principal está viajando por todo el mundo. Sin embargo, este jar no es el otro jar, y el jar generado por el paquete de aplicación springboot sigue siendo diferente del jar tradicional.
Después de empaquetar con el complemento spring-boot-maven-plugin, se
generan dos archivos en el directorio de destino, como se muestra en la figura: mySpringSecurityTest-1.0-SNAPSHOT.jar (ubicado en el lado izquierdo de la imagen) y mySpringSecurityTest- 1.0-SNAPSHOT.jar.original (ubicado en la imagen a la derecha).
De hecho, al mirar el directorio de archivos, puede encontrar que los archivos en xxx.original incluyen código compilado, archivos estáticos y archivos de configuración. Hay dos categorías más en xxx.jar: 1. / org, que en realidad es dependiente en el arranque de primavera. Algunas clases existen en forma de carpetas; 2. / BOOT-INF / lib, que almacena los paquetes jar de terceros de los que depende la aplicación. Es decir, el jar empaquetado por la aplicación springboot es más grande que el jar tradicional, y el nombre oficial es FATJAR.
Cómo ejecutar FATJAR
¿No es fácil de implementar? Es realmente simple, java -jar xxx.jar, pero vale la pena explorar su principio de implementación interna.
Aunque hay una diferencia entre FATJAR y los frascos ordinarios, para el comando java -jar, no presta atención a quién eres. Solo necesitas saber que eres un frasco, ya sea que seas gordo o feo, no lo hagas. presta atención. La especificación estándar de Java define una serie de reglas que deben seguirse como jar, una de las más importantes es el archivo META-INF / MANIFEST.MF en el paquete jar, que configura la clase principal de la entrada del programa. Eche un vistazo al contenido del archivo modificado FATJAR, como se muestra en la figura: ¿
Es extraño que la clase principal no sea la Aplicación definida en el programa (marcada por @SpringBootApplication)? Búsquelo nuevamente, y resultó que colocarse bajo el atributo Start-Class. Efectivamente, el proceso de inicio de springboot realmente no es tan simple, realmente necesita ser estudiado.
Se sabe que JarLauncher es el punto de entrada a la ejecución del programa y el código fuente es:
public class JarLauncher extends ExecutableArchiveLauncher {
static final String BOOT_INF_CLASSES = "BOOT-INF/classes/";
static final String BOOT_INF_LIB = "BOOT-INF/lib/";
public JarLauncher() {
}
protected JarLauncher(Archive archive) {
super(archive);
}
@Override
protected boolean isNestedArchive(Archive.Entry entry) {
if (entry.isDirectory()) {
return entry.getName().equals(BOOT_INF_CLASSES);
}
return entry.getName().startsWith(BOOT_INF_LIB);
}
public static void main(String[] args) throws Exception {
new JarLauncher().launch(args);
}
}
Principio de realización de JarLauncher
protected void launch(String[] args) throws Exception {
JarFile.registerUrlProtocolHandler();
ClassLoader classLoader = createClassLoader(getClassPathArchives());
launch(args, getMainClass(), classLoader);
}
Hizo tres cosas:
- Vuelva a registrar el protocolo jar.
Reemplace el protocolo predeterminado de JDK sun.net.www.protocol.jar.Handler con org.springframework.boot.loader.jar.Handler. El propósito del reemplazo es que FATJAR tenga una parte adicional del archivo (BOOT-INF / lib / Bajo el paquete jar), el nuevo protocolo puede identificar el contenido del paquete jar y resolver el problema de jar in jar. Al igual que /META-INF/spring.factories, también se pueden cargar clases dependientes de terceros. - Defina classthpath y cree el cargador de clases. El
núcleo es el método isNestedArchive, los archivos de recursos se filtran y los archivos de BOOT-INF / lib / y BOOT-INF / classes / se filtran, y el calssloader se crea con ellos como el classpath - Invocación del método sobrecargado
Utilice el cargador de clases en el paso 2 para crear una instancia de aplicación y llame al método principal. El método principal es SpringbootApplication.run (). No investigaré demasiado aquí y lo dejaré para más adelante.
Lanzador de guerra
Casi no hay diferencia entre WarLauncher y JarLauncher. La única diferencia es que la ruta de classpath registrada en ClassLoader es diferente, que se puede encontrar comparando el método isNestedArchive. WEB-INF / classes /, WEB-INF / lib /, WEB- INF / lib-proporcionados pertenecen todos a la ruta de clases. El paquete war empaquetado por el método war es esencialmente un FATJAR, por lo que también puede ser iniciado por java -jar, y al verificar la estructura de directorios del paquete war, puede encontrar que el paquete también puede ser iniciado por el contenedor web.
