Primavera Boot contiene un conjunto adicional de herramientas que pueden hacer que el proceso de desarrollo de aplicaciones sea un poco más agradable. El módulo spring-boot-devtools se puede agregar a cualquier proyecto para proporcionar funcionalidad adicional durante el desarrollo. Para implementar la compatibilidad con devtools, agregue una dependencia de módulo a su compilación, como se muestra en los siguientes listados para Maven y Gradle:

Maven
<dependencias> <dependencia> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <opcional>verdadero</opcional> </dependencia> </dependencies>
Gradle
dependencias { developmentOnly("org.springframework.boot:spring- boot-devtools") }
Las herramientas de desarrollo se desactivan automáticamente cuando se ejecuta una aplicación completamente empaquetada . Si su aplicación se ejecuta a través de java -jar o un cargador de clases personalizado, entonces se considera una "aplicación de producción". Puede controlar esta lógica operativa utilizando la propiedad del sistema spring.devtools.restart.enabled. Para habilitar devtools independientemente del cargador de clases utilizado para iniciar la aplicación, establezca la propiedad del sistema -Dspring.devtools.restart.enabled=true. Esto no debe hacerse en un entorno de producción donde la ejecución de devtools representa un riesgo de seguridad. Para deshabilitar devtools, excluya la dependencia o establezca la propiedad del sistema -Dspring.devtools.restart.enabled=false.
Si marca la dependencia en Maven como opcional o usa la configuración developmentOnly en Gradle (como se muestra arriba), esto evitará que devtools se aplique transitivamente a otros módulos que usan su proyecto.
Los archivos reempaquetados no contienen devtools de forma predeterminada. Si desea utilizar una función remota de devtools específica, debe incluirla. Cuando utilice el complemento Maven, establezca la propiedad excludeDevtools en false. Cuando utilice el complemento Gradle, configure el classpath para que la tarea contenga la configuración developmentOnly.

Diagnóstico de problemas de carga de clases

La funcionalidad de reinicio tiene Se ha implementado utilizando dos cargadores de clases. Para la mayoría de las aplicaciones, este enfoque funciona bien. Sin embargo, a veces puede provocar problemas de carga de clases, especialmente en proyectos de varios módulos.

Para diagnosticar si los problemas de carga de clases son realmente causados ​​ por devtools y sus dos cargadores de clases, intente deshabilitar el reinicio

.

Si esto resuelve sus problemas, configure el reinicio del cargador de clases para cubrir todo su proyecto.

Propiedades predeterminadas

Algunas bibliotecas admitidas por Spring Boot usan cachés para mejorar el rendimiento. Por ejemplo, los motores de plantillas almacenan en caché las plantillas compiladas para evitar analizar repetidamente los archivos de plantilla. Además, Spring MVC puede agregar encabezados de almacenamiento en caché HTTP a las respuestas cuando se procesan recursos estáticos.

Si bien el almacenamiento en caché es muy útil en un entorno de producción, puede ser contraproducente durante el desarrollo, ya que le impide ver los cambios que se acaban de realizar. incluido en la solicitud. Por este motivo, spring-boot-devtools deshabilita la configuración de caché de forma predeterminada.

La configuración de caché generalmente se configura usando la configuración en el archivo application.properties. Por ejemplo, Thymeleaf proporciona una propiedad spring.thymeleaf.cache. En lugar de configurar estas propiedades manualmente, el módulo spring-boot-devtools aplica automáticamente la configuración adecuada durante el desarrollo.

La siguiente tabla enumera todas las propiedades aplicadas:

Nombre Valor predeterminado

server.error.include-binding-errors

siempre

server.error.include-message

siempre

servidor.error.include -stacktrace

siempre

server.servlet.jsp.init-parameters.development

true

servidor.servlet.sesión.persistent

verdadero

spring.freemarker.cache

falso

spring.graphql.graphiql.enabled

verdadero

spring.groovy.template.cache

falso

spring.h2.console.enabled

verdadero

primavera.mustache. servlet.cache

false

spring.mvc.log-resolved-exception

true

spring.reactor.debug

verdadero

spring.template.provider.cache

false

spring.thymeleaf.cache

falso

spring.web.resources.cache.period

0

spring.web.resources.chain.cache

false
Si no desea que se aplique la configuración predeterminada, puede establecer spring.devtools.add-properties en false en el file application.properties.

Debido a que el desarrollo de aplicaciones Spring MVC y Spring WebFlux requiere más información sobre las solicitudes web, las herramientas de desarrollo sugieren habilitar el registro DEBUG para Grupos de registro web. Esto brindará información sobre la solicitud entrante, qué controlador la está procesando, el resultado de la respuesta y otros detalles. Si desea registrar todos los detalles de la solicitud (incluida la información potencialmente confidencial), puede habilitar spring.mvc.log-request-details o spring.codec.log-request-details propiedades de configuración del.

Java webinar

Reinicio automático

Las aplicaciones que utilizan spring-boot-devtools se reinician automáticamente cuando se modifican los archivos en el classpath. Esta puede ser una característica útil cuando se trabaja en un IDE, ya que proporciona comentarios muy rápidos para realizar cambios en el código. De forma predeterminada, cualquier entrada en el classpath que apunte a un directorio se monitorea para detectar cambios. Tenga en cuenta que algunos recursos, como el contenido estático y las plantillas de visualización, no requieren reiniciar la aplicación.

Iniciar un reinicio

Debido a que DevTools rastrea los recursos en el classpath, la única forma de iniciar un reinicio es actualizando el classpath. Independientemente de si utiliza el IDE o uno de los complementos de compilación, los archivos modificados deben volver a compilarse para activar un reinicio. La forma en que se actualiza el classpath depende de la herramienta utilizada:

  • En Eclipse, guardar un archivo modificado actualiza el classpath y activa un reinicio.

  • En IntelliJ IDEA, construir un proyecto (Build +→+ Build Project) tiene el mismo efecto.

  • Si usa un complemento de compilación, ejecute mvn compile para Maven o gradle build para Gradle activará un reinicio.

Si el reinicio se realiza usando Maven o Gradle mediante un complemento de compilación, entonces debe dejar el valor de forking establecido en habilitado. Si desactiva la bifurcación, el cargador de clases aislado de la aplicación utilizado por devtools no se creará y el reinicio no funcionará como se esperaba.
El reinicio automático funciona muy bien cuando se usa con LiveReload. Si está utilizando JRebel, las recargas automáticas están deshabilitadas a favor de la recarga dinámica de clases. Otras funciones de devtools (como LiveReload y anulación de propiedades) seguirán siendo utilizables.
DevTools utiliza un gancho de terminación del contexto de la aplicación para cerrarla durante el reinicio. No funcionará correctamente si el enlace de apagado está deshabilitado (SpringApplication.setRegisterShutdownHook(false)).
DevTools necesita configure el cargador ResourceLoader utilizado por ApplicationContext. Si su aplicación ya proporciona dicho cargador, se empaquetará. No se admite la anulación directa del método getResource en ApplicationContext.
El reinicio automático no es posible compatible cuando se utiliza un enlace a través de AspectJ.
Reiniciar y recargar

La tecnología de reinicio proporcionada por Spring Boot funciona utilizando dos cargadores de clases. Las clases que no cambian (por ejemplo, clases de archivos jar de terceros) se cargan en el cargador de clases principal. Las clases que se desarrollan activamente se cargan en el cargador de clases restart. Si se reinicia la aplicación, el cargador de clases restart se usa una vez y se crea uno nuevo. Este enfoque significa que reiniciar la aplicación suele ser mucho más rápido que un inicio en frío porque el cargador de clases principalya está disponible y lleno.

Si descubre que el reinicio no es lo suficientemente rápido de sus aplicaciones o está experimentando problemas de carga de clases, es posible que desee consultar tecnologías de recarga como JRebel desde Cambio Cero. Funcionan reescribiendo las clases a medida que se cargan para que sea más fácil volver a cargarlas.

Registrar cambios en el cálculo de estado

De forma predeterminada, cada vez que Cuando se reinicia la aplicación, se registra un informe que muestra el delta de cálculo del estado. El informe muestra cambios en la configuración automática de su aplicación a medida que realiza cambios, como agregar o eliminar beans y establecer propiedades de configuración.

Para deshabilitar el registro de informes, establezca la siguiente propiedad:

Propiedades
spring.devtools.restart.log-condition-evaluación-delta=false
Yaml
spring:
        devtools: restart: log-condition-evaluación-delta: false

Exclusión de recursos

Algunos recursos no necesariamente necesitan activar una recarga cuando cambian. Por ejemplo, las plantillas de Thymeleaf se pueden editar en el mismo lugar. De forma predeterminada, cambiar los recursos en /META-INF/maven, /META-INF/resources, /resources, /static, /public o /templates no activa un reinicio, pero sí una recarga en tiempo real. Si desea configurar estas excepciones, puede utilizar la propiedad spring.devtools.restart.exclude. Por ejemplo, para excluir solo /static y /public, establecería la siguiente propiedad:

Propiedades
spring.devtools.restart.exclude=static/**,public/**
Yaml
spring: devtools: reiniciar: excluir: "static/**,public/**"
Si desea mantener estos valores predeterminados y agregar excepciones adicionales, use spring.devtools. restart.additional-exclude propiedad .

Seguimiento de rutas adicionales

Es posible que desee que la aplicación se reinicie o se vuelva a cargar después de realizar cambios en los archivos que no están en la ruta de clase. Para hacer esto, use la propiedad spring.devtools.restart.additional-paths para configurar rutas adicionales para el seguimiento de cambios. Puede utilizar la propiedad spring.devtools.restart.exclude para controlar si los cambios en rutas adicionales desencadenarán un reinicio completo o un reinicio en tiempo real.

Deshabilitar el reinicio

Si no necesita utilizar la función de reinicio, puede desactivarla utilizando la propiedad spring.devtools.restart.enabled. En la mayoría de los casos, puede establecer esta propiedad en el archivo application.properties (esto aún inicializará el cargador de clases que se reinicia, pero no se realizará un seguimiento de los cambios en el archivo).

Si es necesario completamente deshabilita el soporte de reinicio (por ejemplo, porque no funciona con una determinada biblioteca), luego, antes de llamar a SpringApplication.run(…​), debes configurar el System para spring.devtools.restart.enabled a false, como se muestra en el siguiente ejemplo:

Java
importar org.springframework.boot.SpringApplication; importar org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication clase pública MiAplicación { public static void main(String[] args) { System.setProperty("spring.devtools.restart.enabled", "false"); SpringApplication.run(MiAplicación.clase, args); } }
Kotlin
importar org.springframework.boot.SpringApplication importar org.springframework.boot.autoconfigure.SpringBootApplication @SpringBootApplication objeto MyApplication { @JvmStatic fun main(args: Array<String> ) { System.setProperty("spring.devtools.restart.enabled", "false") SpringApplication.run(MyApplication::class.java, *args) } }

Uso de un archivo activador

Si está trabajando con un IDE que compila constantemente archivos que cambian, es posible que prefiera activar una recarga solo en ciertos momentos. Para hacer esto, puede usar un "archivo activador", que es un archivo especializado que debe modificarse si realmente desea activar la verificación de reinicio.

Cualquier archivo de actualización activa una verificación, pero el reinicio solo ocurre si Devtools detecta que necesita hacer algo.

Para usar un archivo activador, establezca la propiedad spring.devtools.restart. trigger-file al nombre (excluyendo la ruta) de su archivo desencadenante. El archivo desencadenante debe estar en algún lugar de su classpath.

Por ejemplo, si tiene un proyecto con la siguiente estructura:

src +- main +- resources +- .reloadtrigger

Entonces la propiedad de tu el archivo disparador será así:

Propiedades
spring.devtools.restart.trigger-file= .reloadtrigger
Yaml
spring: devtools: reiniciar: disparador- file: ".reloadtrigger "

El reinicio ahora solo se producirá cuando se actualice src/main/resources/.reloadtrigger.

Es posible que desees configurar spring.devtools.restart.trigger-file como una configuración global para que todos tus proyectos tengan la misma lógica.

Algunos IDE tienen características que eliminan la necesidad de actualizar manualmente el archivo desencadenante. Spring Tools para Eclipse y IntelliJ IDEA (Ultimate Edition) tiene este tipo de herramientas de soporte. En Spring Tools, puede usar el botón "recargar" desde la vista de la consola (suponiendo que su trigger-file se llame .reloadtrigger). Para IntelliJ IDEA, puede seguir las instrucciones en la documentación correspondiente.

Configuración de un cargador de clases de reinicio

La funcionalidad de reinicio se implementa a través de dos cargadores de clases. Si surge algún problema, es posible que deba configurar qué se carga con qué cargador de clases.

De forma predeterminada, cualquier proyecto abierto en su IDE se carga con un cargador de clases de "reinicio" y cualquier normal. El archivo jarse carga con el cargador de clases "principal". Lo mismo ocurre si se utiliza mvn spring-boot:run o gradle bootRun: un proyecto que contiene la anotación @SpringBootApplication se carga con "restart " el cargador de clases, y todo lo demás con el cargador de clases "principal".

Puede decirle a Spring Boot que cargue los componentes del proyecto con un cargador de clases diferente creando un archivo META-INF/spring- devtools.properties. El archivo spring-devtools.properties puede contener propiedades con los prefijos restart.exclude y restart.include. Los elementos include son componentes que deben insertarse en el cargador de clases de "reinicio", y los elementos exclude son elementos que deben insertarse en el cargador de clases "principal". El valor de la propiedad es un patrón de expresión regular que se aplica al classpath, como se muestra en el siguiente ejemplo:

Propiedades
 restart.exclude .companycommonlibs=/mycorp-common-[\\w\\d-\\.]+\\.jar restart.include.projectcommon=/mycorp-myproj-[\\w\\d-\\. ]+\ \.jar
Yaml
reiniciar: excluir: companycommonlibs: " /mycorp-common-[\\w\\d-\\.]+\\.jar" incluye: projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\ \.jar "
Todas las claves de propiedad deben ser únicas. Si una propiedad comienza con restart.include. o restart.exclude., entonces se tiene en cuenta.
Carga todo META-INF/spring-devtools.properties desde el classpath. Puede empaquetar archivos dentro de su proyecto o en las bibliotecas que utiliza el proyecto.

Limitaciones conocidas

La funcionalidad de reinicio no funciona muy bien con objetos que se deserializan utilizando el estándar. ObjectInputStream. Si necesita deserializar datos, es posible que necesite usar ConfigurableObjectInputStream de Spring en combinación con Thread.currentThread().getContextClassLoader().

Desafortunadamente , algunas bibliotecas de terceros se deserializan sin tener en cuenta el cargador de clases de contexto. Si encuentra un problema de este tipo, deberá solicitar una solución a los creadores.

LiveReload

El módulo spring-boot-devtools contiene un -en el servidor LiveReload, que se puede utilizar para activar una actualización del navegador cuando cambia un recurso. Las extensiones de navegador LiveReload para Chrome, Firefox y Safari están disponibles gratuitamente en livereload.com.

Si no necesita iniciar el servidor LiveReload cuando ejecuta la aplicación, puede establecer la propiedad spring.devtools.livereload.enabled en false.

Solo se puede ejecutar un servidor LiveReload a la vez. Antes de iniciar la aplicación, asegúrese de que no se estén ejecutando otros servidores LiveReload. Si ejecuta varias aplicaciones desde el IDE, solo la primera admitirá LiveReload.
Para activar LiveReload cuando cambia un archivo, se debe habilitar el reinicio automático. .

Configuración global

Puede configurar los ajustes globales de devtools agregando cualquiera de los siguientes archivos al directorio $HOME/.config/spring-boot:

  1. spring-boot-devtools.properties

  2. spring-boot-devtools. yaml

  3. spring-boot-devtools.yml

Cualquier propiedad agregado a Estos archivos se aplican a todas las aplicaciones Spring Boot en su máquina que usan devtools. Por ejemplo, para configurar el reinicio para usar siempre un archivo activador, agregaría la siguiente propiedad al archivo spring-boot-devtools:

Propiedades
spring.devtools.restart.trigger-file=.reloadtrigger
Yaml
spring: devtools: restart: trigger-file: ".reloadtrigger"

Predeterminado $HOME es el directorio de inicio del usuario. Para configurar esta ubicación, establezca la variable de entorno SPRING_DEVTOOLS_HOME o la propiedad del sistema spring.devtools.home.

Si no se encuentran archivos de configuración devtools en $HOME/.config/spring-boot, se buscará en la raíz del directorio $HOME la presencia de un archivo .spring-boot-devtools.properties. Esto permitirá que la configuración global devtools se comparta con aplicaciones que se ejecutan en una versión anterior de Spring Boot que no admite la ubicación $HOME/.config/spring-boot.

Los perfiles no son compatibles con los archivos de propiedades/yaml para devtools.

Cualquier perfil habilitado en .spring-boot-devtools .properties , no afectará la descarga de archivos asociados a un perfil específico. Nombres de archivos específicos del perfil (como spring-boot-devtools-<profile>.properties) y documentos spring.config.activate.on-profile en archivos y propiedades YAML no son compatibles.

Configuración de un observador del sistema de archivos

FileSystemWatcher está funcionando mediante sondear cambios de clase en ciertos intervalos de tiempo y luego esperar un período predefinido de inactividad para garantizar que no haya más cambios. Debido a que Spring Boot depende completamente del IDE para compilar y copiar archivos en una ubicación donde Spring Boot pueda leerlos, es posible que algunos cambios no se reflejen cuando reinicie su aplicación usando devtools. Si experimenta problemas como este constantemente, intente aumentar las configuraciones spring.devtools.restart.poll-interval y spring.devtools.restart.quiet-period a valores que coincida con su entorno de desarrollo:

Propiedades
spring.devtools.restart.poll-interval=2s spring.devtools.restart. quiet-period= 1s
Yaml
spring: devtools: reiniciar : poll-interval : "2s" quiet-period: "1s"

Los directorios de classpath monitoreados ahora se sondean cada 2 segundos para detectar cambios, y cada 1 segundo Se observa un período de silencio para garantizar que no haya cambios adicionales en las clases.

Aplicaciones remotas

Las herramientas de desarrollo de Spring Boot no se limitan al desarrollo local. También puede utilizar varias funciones al ejecutar aplicaciones de forma remota. Las herramientas de soporte al trabajo remoto son opcionales porque su activación puede suponer un riesgo de seguridad. Sólo deben habilitarse cuando se trabaja en una red confiable o si están protegidos por SSL. Si ninguna de estas opciones está disponible, no debe utilizar las herramientas de soporte remoto para DevTools. Bajo ninguna circunstancia debe habilitar herramientas de soporte durante una implementación de producción.

Para habilitar el soporte, debe asegurarse de que devtools esté incluido en el archivo reempaquetado, como se muestra en la siguiente lista: 

 <compilación> <complementos> <complemento> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuración> <excludeDevtools>false</excludeDevtools> </configuración> </complemento> </complementos> </build>

Luego debe configurar la propiedad spring.devtools.remote.secret. Como cualquier contraseña importante o información confidencial, el valor debe ser único y seguro para que no pueda adivinarse ni forzarse de forma bruta.

Las herramientas de soporte remoto de devtools se proporcionan en dos partes: un punto final del lado del servidor, receptor de conexión y una aplicación cliente que ejecuta en su IDE. El componente del servidor se activa automáticamente si se establece la propiedad spring.devtools.remote.secret. El componente del cliente debe iniciarse manualmente.

El trabajo remoto con devtools no es compatible con las aplicaciones Spring WebFlux.

Ejecutar un control remoto aplicación cliente

La aplicación cliente remota está diseñada para ejecutarse desde su IDE. Debe ejecutar org.springframework.boot.devtools.RemoteSpringApplication con la misma ruta de clases que el proyecto remoto al que se está conectando. El único argumento requerido para la aplicación es la URL remota a la que se conecta.

Por ejemplo, si está utilizando Eclipse o Spring Tools y tiene un proyecto llamado my-app que está implementado en Cloud Foundry, debe hacer lo siguiente:

  • Seleccione Ejecutar configuraciones…​ en el menú Ejecutar.

  • Cree una nueva "configuración de inicio" Aplicación Java.

  • Encuentre el proyecto mi-aplicación.

  • Utilice org.springframework.boot.devtools.RemoteSpringApplication como clase principal.

    < /li>

  • Agregue https://myapp.cfapps.io en Argumentos del programa (o cualquiera que sea su URL de acceso remoto).

El cliente remoto en ejecución podría verse así:

 . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ ___ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | | _ \___ _ __ ___| |_ ___ \ \ \ \ \\/ ___)| |_)| | | | | || (_| []::::::[] / -_) ' \/ _ \ _/ -_) ) ) ) ) ' |____| .__|_| |_|_| |_\__, | |_|_\___|_|_|_\___/\__\___|/ / / / =========|_|============== |___/====================================/_/_/_/ :: Arranque de primavera Remoto :: (v2.7.5) 2022-10-20 12:40:15.175 INFO 16215 --- [principal] o.s.b.devtools.RemoteSpringApplication: Iniciando RemoteSpringApplication v2.7.5 usando Java 1.8.0_345 en myhost con PID 16215 (/Usuarios/ myuser /.m2/repository/org/springframework/boot/spring-boot-devtools/2.7.5/spring-boot-devtools-2.7.5.jar iniciado por myuser en /opt/apps/) 2022-10-20 12 : 40:15.182 INFORMACIÓN 16215 --- [principal] o.s.b.devtools.RemoteSpringApplication: No hay ningún perfil activo establecido, volviendo a 1 perfil predeterminado: "predeterminado" 2022-10-20 12:40:15.913 INFORMACIÓN 16215 --- [principal] o.s.b.d.a.OptionalLiveReloadServer: el servidor LiveReload se ejecuta en el puerto 35729 2022-10-20 12:40:15.946 INFO 16215 --- [principal] o.s.b.devtools.RemoteSpringApplication: se inició RemoteSpringApplication en 1.471 segundos (JVM ejecutándose durante 2.063)
Debido a que el cliente remoto usa la misma ruta de clases que la aplicación real, puede leer directamente las propiedades de la aplicación. Esto lee la propiedad spring.devtools.remote.secret y la pasa al servidor para su autenticación.
Siempre es Se recomienda utilizar https:// como protocolo de conexión para que el tráfico esté cifrado y las contraseñas no puedan interceptarse.
Si necesita usar un proxy para acceder a una aplicación remota, configure las propiedades spring.devtools.remote.proxy.host y spring.devtools.remote.proxy.port.

Actualización remota

El cliente remoto monitorea los cambios en el classpath de su aplicación de la misma manera que lo hace un programa de reinicio local. Cualquier recurso actualizado se pasa a la aplicación remota y (si es necesario) activa un reinicio. Esto puede resultar útil si está repitiendo una función que utiliza un servicio en la nube que no está disponible localmente. En general, una actualización y un reinicio remotos son mucho más rápidos que una reconstrucción e implementación completas.

En un entorno de desarrollo lento, es posible que el período de inactividad sea insuficiente y los cambios en las clases se puedan dividir en lotes. . El servidor se reiniciará después de descargar el primer lote de cambios de clase. El siguiente paquete no se puede enviar a la aplicación porque el servidor se está reiniciando.

Esto generalmente genera una advertencia en los registros de RemoteSpringApplication de que algunas clases no se pudieron cargar y luego se vuelve a intentar. . Pero esto también puede dar como resultado un código de aplicación inconsistente y la imposibilidad de reiniciar después de descargar el primer lote de cambios. Si experimenta problemas como este constantemente, intente aumentar las configuraciones spring.devtools.restart.poll-interval y spring.devtools.restart.quiet-period a valores que coincida con su entorno de desarrollo.

Los archivos se rastrean solo mientras se ejecuta el cliente remoto. Si cambia un archivo antes de que se ejecute el cliente remoto, no se transferirá al servidor remoto.