Entrevistador: Quiero ejecutar el proyecto Spring Boot en tomcat, ¿cómo debo configurarlo?

Introducción

1. Heredar SpringBootServletInitializer y anular el método de configuración
2. El alcance de spring-boot-starter-tomcat se cambia a proporcionado
3. Cambia el método de empaque a guerra

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-tomcat</artifactId>
  <scope>provided</scope>
</dependency>

<packaging>war</packaging>

Esta pregunta generalmente se hace para ver si está familiarizado con el alcance y su función. Solo responde el alcance

Introduzcamos brevemente el conocimiento relevante de maven

Los días antes de Maven

Un pequeño sentimiento personal, aprender una nueva tecnología, debería mirar las razones del surgimiento de esta nueva tecnología desde una perspectiva histórica y qué problemas nos ayudó a resolver. ¿Recordemos cómo era sin Maven?

1. Para desarrollar un proyecto, necesita usar un paquete jar escrito por otros. Primero descargamos el paquete jar de código abierto y lo colocamos en el directorio lib del proyecto, y agregamos este directorio a CLASSPATH (dígale al entorno de ejecución de Java, en qué directorios puede encontrar su clase o paquete requerido por el programa Java para ser ejecutado)
2. Descargamos a.jar y descubrimos que a.jar también necesita depender de b.jar, y luego descargamos el paquete b.jar y comenzamos a ejecutar
3. Si tiene la suerte, nuestro proyecto podrá ejecutarse correctamente después de agregar todas las dependencias. Si tiene casi suerte, encontrará problemas de versión. Por ejemplo, cuando a.jar llama a b.jar, descubre que b.jar no tiene este método en absoluto. Solo está disponible en otras versiones. Ahora está bien. Solo busque dependencias y adaptaciones. La versión puede llevar mucho tiempo
4. Y cuando cargamos código en git, debemos cargar todas estas bibliotecas. Cuando otros descargan nuestro código, también deben descargar la biblioteca, lo que requiere mucho tiempo.

En este momento, Maven apareció como una herramienta de gestión de paquetes en el mundo de Java. Por supuesto, existen otras herramientas de gestión de paquetes en el mundo de Java, como gradle. Al igual que yum es una herramienta de gestión de paquetes en el mundo Linux y webpack es una herramienta de gestión de paquetes en el mundo front-end

Tipos de repositorios de Maven

El proceso de Maven en busca de un paquete jar es así: primero búsquelo en el almacén local, luego vaya al servidor privado (si está configurado) y luego vaya al almacén central (http://repo1.maven.org/ maven2 /, el equipo de maven es responsable del mantenimiento)

Después de ser encontrado en el almacén central, se colocará una copia en el servidor privado y en el almacén local, y también se colocará una copia en el almacén local cuando se encuentre en el servidor privado.

Después de haber instalado Maven, hay un archivo settings.xml en el directorio conf. Hay muchos elementos de configuración en este archivo. Este archivo de configuración se describirá en detalle más adelante.

<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->

Hay este párrafo en este archivo de configuración, que dice que la dirección del almacén local predeterminada de Maven es $ {user.home} /. M2 / repository (por supuesto, puede restablecer la dirección del almacén local, lo anterior es la plantilla), Soy una computadora con ventana, eche un vistazo a este directorio y

vea que hay muchos paquetes jar almacenados localmente. Por supuesto, si desea configurar el servidor privado, también está configurado en settings.xml. Solo busque muchos tutoriales y no repetirlos.

La construcción de un servidor privado tiene muchos beneficios: en una empresa, algunos componentes públicos básicos se pueden desarrollar y colocar en el servidor privado para que otros colegas los utilicen.

Configuración predeterminada de Maven

La estructura general de

un proyecto Maven es así: ¿Por qué la estructura de archivos de un proyecto Maven es así?
Esto tiene que hablar de una característica de Maven, la convención es mejor que la configuración.

De forma predeterminada, Maven está configurado con $ {project.basedir} / src / main / java como directorio de código fuente del proyecto,
$ {project.basedir} / src / main / test como directorio de código de prueba del proyecto,
$ {project.basedir } / target como directorio de salida de la compilación del proyecto, etc.

Spring Boot es la encarnación de la convención sobre la configuración. Piense en ello cuando usamos Spring MVC, tenemos que configurar el solucionador de vistas y el escaneo automático de paquetes. Con el marco de Spring Boot, no necesitamos configurarlo en absoluto.

Proyecto detallado de Maven

La instalación es bastante simple, no la presentaré y no la descargué por separado. Generalmente, uso el Maven que viene con Idea. La estructura de directorios después de la descarga es la siguiente:

directorio bin:
este directorio contiene scripts ejecutados por mvn. Estos scripts se utilizan para configurar comandos java, preparar classpath y propiedades del sistema Java relacionadas, y luego ejecutar comandos Java.

Directorio de arranque:
este directorio contiene solo un archivo, que es plexus-classworlds-2.5.2.jar. Plexus-classworlds es un marco de carga de clases. En comparación con el cargador de clases predeterminado de Java, proporciona una sintaxis más rica para facilitar la configuración. Maven usa este marco para cargar sus propias bibliotecas de clases.

conf directorio:
este directorio contiene un archivo muy importante settings.xml. Al modificar directamente este archivo, puede personalizar el comportamiento de maven globalmente en la máquina, lo que es efectivo para todos los usuarios. En general, preferimos copiar el archivo al directorio ~ / .m2 / (~ representa el directorio de inicio del usuario, en windows ~ es C: \ Users \ Peng, Peng es el nombre de usuario del editor) y luego modificar el archivo, personalizar el comportamiento de Maven a nivel de usuario.

Directorio Lib:
este directorio contiene todas las bibliotecas de clases Java necesarias para el tiempo de ejecución de Maven. Maven se desarrolla en módulos, por lo que los usuarios pueden ver archivos como maven-core-3.0.jar, maven-model-3.0.jar, etc. , también hay algunas dependencias de terceros que usa Maven, como commons-cli-1.2.jar, commons-lang-2.6.jar, etc. ,

Archivo de configuración detallado settings.xml

Hablemos sobre el archivo settings.xml en detalle. Este archivo puede personalizar el comportamiento de Maven. Como se mencionó anteriormente, settings.xml se puede colocar en 2 ubicaciones, ~ / .m2 / setting.xml (no está disponible de forma predeterminada, necesitamos para copiarlo nosotros mismos) y $ {maven.home} /conf/setting.xml

La secuencia de carga de estos dos archivos de configuración es ~ / .m2 / setting.xml> $ {maven.home} /conf/setting.xml, para no afectar a otros, por lo que copiamos el settings.xml bajo conf a la casa directorio, en Personalizar el comportamiento de Maven a nivel de usuario.

Esto es similar a la configuración de variables de entorno. Tanto Windos como Linux pueden configurar variables de entorno a nivel del sistema y variables de entorno a nivel de usuario. Hablemos solo de Linux. Lo que se configura en / etc / profile son las variables de entorno a nivel del sistema. ~ /. bash_profile está configurado con variables de entorno a nivel de usuario

Hay bastantes elementos de configuración diversos, configurar el almacén espejo (Alibaba Cloud se usa más en China), configurar el proxy, no más detalles

Comandos de uso común de Maven

mando	descripción
mvn -version	Mostrar información de versión
mvn limpio	Eliminar directorio de destino
compilar mvn	Compile el código fuente en src / main / java
paquete mvn	Empaquetar, generar paquete jar o paquete war bajo el objetivo
prueba mvn	Ejecute casos de prueba de clases que comiencen con Test o terminen con Test en src / test / java
instalación de mvn	Empaquete y copie el paquete jar o el paquete war en el almacén local para que lo usen otros módulos
despliegue mvn	Publica los archivos empaquetados en servidores privados.
dependencia de mvn: árbol	Imprima el árbol de dependencias completo del proyecto

Por supuesto, también puede usar
el paquete mvn clean para limpiar el paquete
mvn clean package -DskipTests = true para limpiar el paquete y omitir el caso de prueba
mvn clean install limpiar el paquete y copiar el paquete jar o war al almacén local

Cuando se ejecuta una sola prueba, no es necesario probar los métodos uno por uno. El comando mvn test ejecuta todos los casos de prueba.
Debe tenerse en cuenta que solo se ejecutarán las clases de prueba que comiencen o terminen con Test. No es necesario escribir clases de prueba por ti mismo. Se recomienda leer el primer artículo que demuestra el método de generación rápida de clases de prueba, puedes ir y echar un vistazo, las clases de prueba generadas terminan con Test

Dependencia de mvn: árbol> show.txt redirige la salida de dependencia a un archivo para una fácil visualización

Pom.xml detallado

groupId empresa nombre de dominio invertido
artifactId función comando
versión número de versión

Estas tres dimensiones determinan un paquete jar, al igual que usar las coordenadas (x, y, z) para determinar de forma única un punto en el espacio tridimensional.

empaquetado Método de empaquetado, jar, war, maven-plugin (desarrollo de maven plugin)

Alcance detallado

parámetro	Explicación	¿Se ingresará en el paquete final del frasco?
compilar	Alcance predeterminado	si
prueba	Prueba de uso	No
previsto	Necesidades de compilación	No
tiempo de ejecución	No se requiere para la compilación, se requiere en tiempo de ejecución (separación de interfaz e implementación)	si
sistema	Cargar jar local	No

Similar a lo siguiente, no se especifica ningún alcance, lo que indica que el alcance se compila

<dependency>
	<groupId>org.mybatis.spring.boot</groupId>
	<artifactId>mybatis-spring-boot-starter</artifactId>
	<version>1.3.2</version>
</dependency>

La prueba se usa cuando se ejecutan casos de prueba, no es necesario ingresar al jar final, por lo que el alcance del marco de prueba que ve es básicamente prueba

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-test</artifactId>
	<scope>test</scope>
</dependency>

proporcionado, se usará al compilar, pero no se ingresará en el paquete jar final.
Por ejemplo, si desea ejecutar el proyecto de arranque de primavera en tomcat como un paquete de guerra, primero debe agregar las siguientes dependencias

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-tomcat</artifactId>
	<scope>provided</scope>
</dependency>

O escribiste una tarea para que se ejecutara en un clúster de Storm o Flink, y finalmente estableciste la dependencia de Storm o Flink como proporcionada, porque el clúster ya tiene paquetes jar para estos entornos,

Si usa el complemento de lombok, encontrará que el Maven de lombok tiene la siguiente forma, lo que indica que solo se usará durante la compilación.

<dependency>
	<groupId>org.projectlombok</groupId>
	<artifactId>lombok</artifactId>
	<version>1.16.6</version>
	<scope>provided</scope>
</dependency>

Escribí una clase de prueba de la siguiente manera

@Data
public class Test {
    
    

    private String name;
    private int age;
}

El archivo de clase generado después de la descompilación es el siguiente, lo que verifica nuestra idea. Después de la compilación, de hecho es innecesario utilizar el paquete jar de lombok

public class Test {
    
    
    private String name;
    private int age;

    public Test() {
    
    
    }

    public String getName() {
    
    
        return this.name;
    }

    public int getAge() {
    
    
        return this.age;
    }

    public void setName(String name) {
    
    
        this.name = name;
    }

    public void setAge(int age) {
    
    
        this.age = age;
    }
}

runtime, solo se usa en runtime. Por ejemplo, si su proyecto tiene operaciones en la base de datos, pero no agrega el paquete jar de implementación de JDBC correspondiente, como mysql-connector-java, se puede compilar correctamente y solo se informará de un error en tiempo de ejecución. Entonces verá que el alcance del paquete jar implementado por JDBC es el tiempo de ejecución, lo que indica que este paquete jar solo se usará en tiempo de ejecución

<dependency>
	<groupId>mysql</groupId>
	<artifactId>mysql-connector-java</artifactId>
	<version>5.1.35</version>
	<scope>runtime</scope>
</dependency>

sistema, cargue el jar localmente, cuando coopere con una empresa de terceros y simplemente le den un paquete jar, tiene tres opciones

1. mvn instalar en el almacén local
2. Implementar mvn en un servidor privado
3. Especifique la ruta del paquete jar y cárguelo localmente, como el siguiente formulario pom

 <dependency>
	<groupId>com.tievd.third</groupId>
	<artifactId>arcvideo</artifactId>
	<version>1.0</version>
	<scope>system</scope>
	<systemPath>${basedir}/lib/face-api-1.0.jar</systemPath>
</dependency>

Como se mencionó anteriormente, la dependencia del alcance como sistema no se ingresará en el paquete jar final. Es necesario ingresar la dependencia en el paquete jar final configurando complementos, por lo que este método generalmente se usa raramente.

Pase de dependencia

Supongamos que ahora tenemos un proyecto de varios módulos y la relación de dependencia se muestra en la figura. Cuando introducimos la dependencia st-dal en el módulo st-web, también introduciremos la dependencia st-common-lib. Esta es la transferencia de dependencia , como se enumera en la siguiente tabla Se enumeran los cambios en el alcance durante el proceso de dependencia, los encabezados de columna son los módulos que son dependientes y los módulos de los que depende cada comportamiento

	compilar	prueba	previsto	tiempo de ejecución
compilar	compilar	-	-	tiempo de ejecución
prueba	prueba	-	-	prueba
previsto	previsto	-	previsto	previsto
tiempo de ejecución	tiempo de ejecución	-	-	tiempo de ejecución

Bienvenido a seguir