spring boot 笔记--第三章

spring boot 笔记

第三章，使用Spring boot

• 构建系统：

强烈建议支持依赖管理的构建系统，Maven或Gradle

• 依赖管理：

Spring Boot的每版本都会提供它支持的依赖列表。构建配置中不需要提供这些依赖的版本，因为Spring Boot会帮你进行管理。升级Spring Boot时，这些依赖也会随之升级。

可以自己指定版本，覆盖Spring Boot的推荐的依赖版本，但Spring Boot和Spring Framework关联性很强，强烈建议不要指定Spring Framework的版本。

• 继承starter parent：

配置项目继承spring-boot-starter-parent。

 <parent>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-parent</artifactId>
     <version>1.5.8.RELEASE</version>
 </parent>

只需在这里指定<version>，其他starters都可以忽略<version>

继承starter parent后，可通过properties覆盖某些依赖的版本

例子：

 <properties>
     <spring-data-releasetrain.version>Fowler-SR2</spring-data-releasetrain.version>
 </properties>

• 没有父POM的情况下使用Spring Boot：

当需要使用公司的标准父POM时，仍想保留依赖管理的好处，可以使用scope=import依赖

这样就不能用properties覆盖某些依赖的版本，而要在spring-boot-dependencies之前指定依赖的版本

 <dependencyManagement>
     <dependencies>
         <!-- Override Spring Data release train provided by Spring Boot -->
         <dependency>
             <groupId>org.springframework.data</groupId>
             <artifactId>spring-data-releasetrain</artifactId>
             <version>Fowler-SR2</version>
             <scope>import</scope>
             <type>pom</type>
         </dependency>
         <dependency>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-dependencies</artifactId>
             <version>1.5.8.RELEASE</version>
             <type>pom</type>
             <scope>import</scope>
         </dependency>
     </dependencies>
 </dependencyManagement>

更改Java版本：

 <properties>
     <java.version>1.8</java.version>
 </properties>

• 使用Spring Boot Maven插件：

Spring Boot提供了可以将工程打包为一个可执行的jar包的Maven插件

继承了Spring Boot的starter parent时，不需要指定<version>等配置

 <build>
     <plugins>
         <plugin>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-maven-plugin</artifactId>
         </plugin>
     </plugins>
 </build>

• Starters：

启动器包含快速运行一个工程的依赖，并支持依赖传递管理

官方启动器的命名模式：spring-boot-starter-*
第三方启动器命名模式：*-spring-boot-starter

• 代码布局：

Spring Boot不要求特定的代码布局，但有一些最佳实践

避免使用default package，因为使用 @ComponentScan， @EntityScan或 @SpringBootApplication 这些注解时会有问题，Spring Boot会读取所有jar中的所有类

包名建议使用反转的域名，例如：com.example.myproject

建议将主类放在根包中，
因为 @EnableAutoConfiguration经常放在主类中，而 @EnableAutoConfiguration注解隐式的定义了搜索位置
例如JPA应用， @EnableAutoConfiguration注解的类所在的包将被用来搜索 @Entity项

主类在根包中时， @ComponentScan注解主类，不用指定basePackage属性
主类在根包中时，可以用 @SpringBootApplication注解

典型的布局：

 com
  +- example
      +- myproject
          +- Application.java
          |
          +- domain
          |   +- Customer.java
          |   +- CustomerRepository.java
          |
          +- service
          |   +- CustomerService.java
          |
          +- web
              +- CustomerController.java

• 配置类：

Spring Boot倾向于基于Java的配置
尽管SpringApplication.run()可以加载XML资源，网上很多Spring的例子也是使用XML配置，但还是建议用 @Configuration类进行配置。

• 导入额外的配置类：

不必将所有的 @Configuration放到一个类中， @Import可以导入其他配置类
可以用 @ComponentScan来自动扫描Spring组件，包括 @Configuration注解的类

• 导入XML配置：

如果你就是要使用基于XML的配置，推荐还是用 @Configuration注解的类，然后用 @ImportResource注解来加载XML配置文件。

• 自动配置：

Spring Boot会根据添加的jar依赖，自动配置。
例如，添加HSQLDB依赖后，没有手动配置数据库连接bean，Spring Boot会自动配置内存数据库

添加 @EnableAutoConfiguration 或 @SpringBootApplication注解到你的 @Configuration类中来启用自动配置。

一个应用中 @EnableAutoConfiguration注解只能有一个

• 逐渐替换自动配置：

定义自己的配置，就能替换自动配置的相应部分
例如，自己定了DataSource bean，就会覆盖默认的内存数据库

用--debug启动应用，会使核心日志的输出级别变为debug，并输出自动配置报告到控制台。

• 禁用特定的自动配置：

@EnableAutoConfiguration注解的exclude属性能禁用特定的自动配置
如： @EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

如果类不在classpath中，可以用excludeName属性来指定全限定名

还可以用spring.autoconfigure.exclude属性来禁用特定的自动配置

• Spring Beans和依赖注入：

任何标准的Spring框架技术都可以定义beans和注入依赖。
为了简便，常用 @ComponentScan扫描beans，用 @Autowired构造函数注入依赖

主类放在根包中， @ComponentScan注解就不需要参数，组件会自动注册为Spring bean，如 @Component， @Service， @Repository， @Controller等

例如：

 package com.example.myproject.service;
 import org.springframework.beans.factory.annotation.Autowired;
 import org.springframework.stereotype.Service;
 
 @Service
 public class DatabaseAccountService implements AccountService {
 
     //注意使用构造函数注入允许riskAssessor字段标记为final，意味着它接下来不能被修改
     private final RiskAssessor riskAssessor;
 
     @Autowired
     public DatabaseAccountService(RiskAssessor riskAssessor) {
         this.riskAssessor = riskAssessor;
     }
 
     // ...
 
 }

• 使用 @SpringBootApplication注解:

@Configuration， @EnableAutoConfiguration和 @ComponentScan注解常一起用，Spring Boot提供了一个方便的 @SpringBootApplication注解来代替它们

@SpringBootApplication注解等价于默认配置下的 @Configuration， @EnableAutoConfiguration和 @ComponentScan
@SpringBootApplication也提供了别名来定制 @EnableAutoConfiguration和 @ComponentScan对应的属性

• 运行应用：

将应用打包成jar并使用内嵌HTTP服务器就可以在任何地方运行。
调试Spring Boot应用也很容易；你不必使用任何特定的IDE插件或扩展。

• 从IDE运行应用:

Eclipse导入Maven工程,从File菜单选择Import…​ → Existing Maven Projects

一个web应用运行两次，会出现端口被占用的错误，STS可以用Relaunch代替Run按钮

• 直接运行一个打包的应用:

可执行的jar包，可以用java -jar来运行

$ java -jar target/myproject-0.0.1-SNAPSHOT.jar

支持以远程调试模式运行打包的应用。这会在打包的应用中添加一个调试器：

$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n -jar target/myproject-0.0.1-SNAPSHOT.jar

• 使用Maven插件运行应用：

$ mvn spring-boot:run

设置操作系统环境变量

$ export MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128M

• 热部署：

JVM热部署可以替换的字节码有限制，更好的方案是使用JRebel或Spring Loaded，spring-boot-devtools也支持快速重启

• 开发者工具:

spring-boot-devtools模块加到任何工程中，提供程序调试功能

 <dependencies>
     <dependency>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-devtools</artifactId>
         <optional>true</optional>
     </dependency>
 </dependencies>

运行完整的打包应用时，开发者工具会自动失效。

通过java -jar启动，或通过特定的类加载器启动的应用，会被当做『产品级应用』。
将依赖标记为optional是为了阻止devtools间接应用到使用你应用的其它模块。

再打包的文件默认不包含devtools。
如果想使用devtools远程功能，需要配置excludeDevtools属性。

• 自动重启：

当classpath中的文件修改时，spring-boot-devtools会自动重启应用
注意某些资源例如静态资源和视图模板不需要重启应用。

在Eclipse中，保存修改的文件将引起classpath更新并触发重启事件。
在IDEA中，构建工程(Build → Make Project)会引起classpath更新并触发重启事件。

禁用shutdown hook，DevTools将不能正确工作（SpringApplication.setRegisterShutdownHook(false)）。
因为DevTools依赖应用上下文的shutdown hook，在重启期间关闭应用。

DevTools会自动忽略名为spring-boot，spring-boot-devtools，spring-boot-autoconfigure，spring-boot-actuator和spring-boot-starter的工程引起的classpath更新，不会触发重启。

• 重启与重载：

Spring Boot提供的重启技术是通过两个类加载器进行工作的。
加载进基类加载器的类不能改变（例如，那些第三方jar包）。
那些你正在开发的类加载进重启类加载器中。
当应用重启时，丢弃旧的重启类加载器并创建一个新的。
这种方法意味着应用重启时比『冷启动』更快，因为基类加载器已经存在并可用。

如果觉得应用重启不够快，或碰到了类加载问题，可以考虑重载技术，例如ZeroTurnaround的JRebel。
重载技术通过加载时重写类使其更适合重载。

• 例外资源：

某些资源改变时不需要触发重启，例如，Thymeleaf模板可以就地编辑。

默认情况下，/META-INF/maven，/META-INF/resources，/resources，/static，/public或/templates中资源的改变不会触发重启，但会触发实时重载。

如果想定制这些例外项，可以使用spring.devtools.restart.exclude属性。
例如，仅排除/static和/public，设置如下：

spring.devtools.restart.exclude=static/**,public/**

保持默认设置的同时添加例外项，可以用spring.devtools.restart.additional-exclude属性。

• 监控其它路径：

用spring.devtools.restart.additional-paths属性可以监控classpath之外其它路径上的变化。
可以用spring.devtools.restart.exclude属性来控制其它路径上的变化的触发效果，是触发重启还是仅触发实时重载。

• 禁用重启：

通过application.properties中设置spring.devtools.restart.enabled属性禁用，仍会初始化重启类加载器但不会监控文件的变化
要完全禁用重启，调用SpringApplication.run(…​)之前设置System属性：

 public static void main(String[] args) {
     System.setProperty("spring.devtools.restart.enabled", "false");
     SpringApplication.run(MyApp.class, args);
 }

• 使用触发器文件：

想在特定的时间触发重启，可以使用『触发器文件』
修改『触发器文件』只触发重启检查，Devtools决定是否重启。

设置spring.devtools.restart.trigger-file属性来使用触发器文件

将spring.devtools.restart.trigger-file作为全局设置，可以应用到所有的工程

• 定制重启类加载器：

创建META-INF/spring-devtools.properties文件

spring-devtools.properties中可以设置包含restart.exclude.和restart.include.前缀的属性。
include元素会放到“restart”类加载器中，exclude元素会放到“base”类加载器中。
属性值是应用到classpath中的一个正则表达式。

例如：

restart.exclude.companycommonlibs=/mycorp-common-[\\w-]+\.jar
restart.include.projectcommon=/mycorp-myproj-[\\w-]+\.jar

所有属性Key必须是唯一的。

restart.include.或restart.exclude只要配置了就会应用。

可以将META-INF/spring-devtools.properties文件打包进工程中，也可以是工程使用的库中，都会被加载。

• 已知的限制：

使用标准ObjectInputStream进行反序列化对象时，重启功能可能有问题。
可以使用Spring的ConfigurableObjectInputStream和Thread.currentThread().getContextClassLoader()反序列化数据

有些第三方库反序列化时没有考虑上下文类加载器，只能请求原作者修正。

• 实时重载：

spring-boot-devtools模块包含一个内嵌的实时重载服务器，当资源改变时可以用来触发浏览器重新刷新。
livereload.com中的实时重载浏览器扩展可用于Chrome，Firefox和Safari

不想启动实时重载服务器，可以将spring.devtools.livereload.enabled属性设为false

一次只能运行一个实时重载服务器。从IDE中启动多个应用，只有第一个应用支持实时重载服务器。

• 全局设置:

$HOME文件夹中，添加 .spring-boot-devtools.properties文件，可以对开发者工具进行全局设置（注意文件名以.开头）

如：
~/.spring-boot-devtools.properties.

spring.devtools.reload.trigger-file=.reloadtrigger

• 远程应用：

Spring Boot开发者工具不是本地环境才能用，有些功能可以用于远程应用。

再打包的文件中包含devtools，才能开启远程支持：

 <build>
     <plugins>
         <plugin>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-maven-plugin</artifactId>
             <configuration>
                 <excludeDevtools>false</excludeDevtools>
             </configuration>
         </plugin>
     </plugins>
 </build>

还要设置spring.devtools.remote.secret属性

例如：

spring.devtools.remote.secret=mysecret

远程devtools有安全风险，生产环境不应该开启远程支持。

远程devtools分为两部分：
一个接收连接的服务器端，一个运行在IDE中的客户端应用。
当设置spring.devtools.remote.secret属性时，服务器组件会自动起作用。客户端组件必须手动启动。

• 运行远程客户端应用：

远程客户端要运行在 IDE 中。要与远程服务器端使用相同的 classpath ，以便运行 org.springframework.boot.devtools.RemoteSpringApplication。要连接的远程 URL作为参数传入。

因为远程客户端与远程服务器端使用的classpath相同，因此它可以直接读取应用属性。

为了传输的安全性，建议总是使用HTTPS协议。

要使用代理访问远程应用，则要配置spring.devtools.remote.proxy.host和spring.devtools.remote.proxy.port属性。

• 远程更新：

远程客户端会像本地重启那样监控应用的classpath的变化。

任何资源的更新都会推送到远程应用并在需要时触发重启。

如果你在迭代开发一个功能，这个功能使用了本地没有的云服务，这时远程更新就很有用。

通常更新和重启比整个重新构建部署更快。

当远程客户端运行时只监控文件。如果在启动远程客户端之前你修改了文件，它将不会推送到远程服务器。

• 远程调试通道：

在诊断远程应用的问题时，Java远程调试很有用。

devtools 支持通过 HTTP 实现远程调试的通道。

远程客户端提供了在8000端口上的本地服务，你可以在这上面添加一个远程调试器。

建立连接后，调试通信将通过 HTTP 发送到远程应用。

如果要使用不同的端口，可以使用 spring.devtools.remote.debug.local-port 属性。

使用远程调试通道需要确保远程应用启动时启用了远程调试。

可以通过配置 JAVA_OPTS 来实现。例如，使用 Cloud Foundry，您可以向您的 manifest.yml 添加以下内容:

---
    env:
        JAVA_OPTS: "-Xdebug -Xrunjdwp:server=y,transport=dt_socket,suspend=n"

注意：不需要在 -Xrunjdwp 中设置 address=NNNN 。省略address，Java会简单的选择一个随机的可用的端口。

通过网络调试远程服务可能很慢，可能需要在 IDE 中增加超时时间。

例如，在 Eclipse 中，可以从Preferences…​选择Java → Debug，并将Debugger timeout (ms)改成更合适的值(在大多数情况下，60000可以正常工作)。

• 将应用打包成产品：

可执行的 jar 可以用于生产部署。由于它们是自包含的，它们也非常适合基于云的部署。