20191128 Spring Boot官方文档学习（9.11-9.17）
9.11。消息传递
Spring Boot提供了许多包含消息传递的启动器。本部分回答了将消息与Spring Boot一起使用所引起的问题。
9.11.1。禁用事务JMS会话
如果您的JMS代理不支持事务处理会话，则必须完全禁用对事务的支持。如果您创建自己的JmsListenerContainerFactory，则无需做任何事情，因为默认情况下无法进行交易。如果要使用DefaultJmsListenerContainerFactoryConfigurer来重用Spring Boot的默认值，则可以禁用事务处理的会话，如下所示：
@Bean
public DefaultJmsListenerContainerFactory jmsListenerContainerFactory(
ConnectionFactory connectionFactory,
DefaultJmsListenerContainerFactoryConfigurer configurer) {
DefaultJmsListenerContainerFactory listenerFactory =
new DefaultJmsListenerContainerFactory();
configurer.configure(listenerFactory, connectionFactory);
listenerFactory.setTransactionManager(null);
listenerFactory.setSessionTransacted(false);
return listenerFactory;
}
前面的示例将覆盖默认工厂，并且应将其应用于应用程序定义的任何其他工厂（如果有）。
9.12。Batch Applications
本部分回答了将Spring Batch与Spring Boot结合使用所引起的问题。
默认情况下，批处理应用程序需要一个DataSource来存储作业详细信息。批处理在您的上下文中自动装配单个DataSource，并将其用于处理。要让Batch使用应用程序的main DataSource之外的其他DataSource，请声明一个DataSource bean，并用@BatchDataSource注释其@Bean方法。如果这样做并想要两个数据源，请记住创建另一个数据源并将其标记为@Primary。要获得更大的控制权，请实现BatchConfigurer。有关更多详细信息，请参见@EnableBatchProcessing。
有关Spring Batch的更多信息，请参见Spring Batch项目页面。
9.12.1。在启动时执行Spring Batch作业
通过在上下文中的某个位置添加@EnableBatchProcessing（从Spring Batch），可以启用Spring Batch自动配置。
默认情况下，它在启动时在应用程序上下文中执行所有 Jobs（有关详细信息，请参见JobLauncherCommandLineRunner）。您可以通过指定spring.batch.job.names（使用逗号分隔的作业名称模式列表）缩小到一个或多个特定作业。
在命令行上指定作业参数：
与在Environment中设置属性的命令行选项参数不同（即，以--开头，例如--my-property=value），作业参数必须在命令行中指定，而不用破折号（例如jobParam=value）。
如果应用程序上下文包含JobRegistry，则将在注册表中查找spring.batch.job.names中的作业，而不是从上下文中自动装配作业。这是更复杂的系统的常见模式，其中多个作业在子上下文中定义并集中注册。
有关更多详细信息，请参见BatchAutoConfiguration和@EnableBatchProcessing。
9.13。Actuator
Spring Boot包括Spring Boot Actuator。本节回答了经常因使用而引起的问题。
9.13.1。更改执行器端点的HTTP端口或地址
在独立应用程序中，Actuator HTTP端口默认与主HTTP端口相同。要使应用程序在其他端口上侦听，请设置外部属性：management.server.port。要侦听完全不同的网络地址（例如，当您有一个用于管理的内部网络，还有一个用于用户应用程序的外部网络）时，还可以设置management.server.address为服务器可以绑定到的有效IP地址。
9.13.2。自定义“whitelabel”错误页面
如果遇到服务器错误，Spring Boot会安装一个“whitelabel”错误页面，您会在浏览器客户端中看到该错误页面（使用JSON和其他媒体类型的机器客户端应该看到带有正确错误代码的明智响应）。
设置server.error.whitelabel.enabled=false以关闭默认错误页面。这样做将还原您正在使用的servlet容器的默认值。请注意，Spring Boot仍然尝试解决错误视图，因此您应该添加自己的错误页面，而不是完全禁用它。
用自己的方法覆盖错误页面取决于您使用的模板技术。例如，如果您使用Thymeleaf，则可以添加error.html模板。如果使用FreeMarker，则可以添加error.ftlh模板。通常，您需要使用名称解析的error View或@Controller处理/error路径。除非你更换了一些默认配置，你应该在ApplicationContext中找到一个BeanNameViewResolver，所以@Bean命名error是这样做的一个简单的方法。请参阅ErrorMvcAutoConfiguration以获取更多选项。
有关如何在servlet容器中注册处理程序的详细信息，另请参见“错误处理” 部分。
9.13.3。清理明智的值
env和configprops端点返回的信息可能有些敏感，因此默认情况下会清理与某个模式匹配的键（即，它们的值将替换为******）。
Spring Boot对此类键使用明智的默认设置：例如，对任何以单词password，secret，key或token结尾的密钥进行清理。也可以改用正则表达式，例如*credentials.*来清除将credentials单词保留为键一部分的任何键。
可以分别使用management.endpoint.env.keys-to-sanitize和management.endpoint.configprops.keys-to-sanitize来定制要使用的模式。
9.14。Security
本部分解决有关使用Spring Boot时的安全性的问题，包括因将Spring Security与Spring Boot一起使用而引起的问题。
有关Spring Security的更多信息，请参见Spring Security项目页面。
9.14.1。关闭Spring Boot安全性配置
如果在应用程序中用WebSecurityConfigurerAdapter定义@Configuration，它将关闭Spring Boot中的默认Webapp安全设置。
9.14.2。更改UserDetailsService并添加用户帐户
如果你提供了一个AuthenticationManager，AuthenticationProvider或者UserDetailsService类型的@Bean，默认InMemoryUserDetailsManager的@Bean不创建。这意味着您拥有完整的Spring Security功能集（例如各种身份验证选项）。
添加用户帐户的最简单方法是提供您自己的UserDetailsService bean。
9.14.3。在代理服务器后运行时启用HTTPS
对于所有应用程序而言，确保所有主要端点仅可通过HTTPS进行访问都是一项重要的工作。如果您将Tomcat用作servlet容器，如果检测到某些环境设置，则Spring Boot会自动添加Tomcat自己的RemoteIpValve，并且您应该能够依靠HttpServletRequest报告其是否安全（甚至在处理真正的SSL终端代理服务器的下游）。标准行为由某些请求标头（x-forwarded-for和x-forwarded-proto）的存在或不存在决定，它们的名称是常规名称，因此它应适用于大多数前端代理。您可以通过向application.properties中添加一些条目来打开开关，如以下示例所示：
server.tomcat.remote-ip-header=x-forwarded-for
server.tomcat.protocol-header=x-forwarded-proto
（这些属性中的任何一个的存在都会打开开关。或者，可以通过添加一个TomcatServletWebServerFactory bean 来添加RemoteIpValve。）
要将Spring Security配置为要求所有（或某些）请求使用安全通道，请考虑添加自己的添加了以下HttpSecurity配置的WebSecurityConfigurerAdapter：
@Configuration(proxyBeanMethods = false)
public class SslWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
// Customize the application security
http.requiresChannel().anyRequest().requiresSecure();
}
}
9.15。热部署
Spring Boot支持热部署。本部分回答有关其工作方式的问题。
9.15.1。重新加载静态内容
有几种热加载选项。推荐的方法是使用spring-boot-devtools，因为它提供了其他开发时功能，例如对快速应用程序重新启动和LiveReload的支持，以及合理的开发时配置（例如模板缓存）。Devtools通过监视类路径的更改来工作。这意味着必须“构建”静态资源更改才能使更改生效。默认情况下，当您保存更改时，这在Eclipse中自动发生。在IntelliJ IDEA中，“生成项目”命令将触发必要的构建。由于默认的重新启动排除项，对静态资源的更改不会触发应用程序的重新启动。但是，它们确实会触发实时重新加载。
另外，在IDE中运行（特别是在调试时）是进行开发的好方法（所有现代IDE都允许重新加载静态资源，并且通常还允许热加载Java类更改）。
最后，可以配置Maven和Gradle插件（请参阅addResources属性）以支持从命令行运行，并直接从源中重新加载静态文件。如果要使用高级工具编写该代码，则可以将其与外部css/js编译器进程一起使用。
9.15.2。重新加载模板，而无需重新启动容器
Spring Boot支持的大多数模板技术都包含禁用缓存的配置选项。如果使用spring-boot-devtools模块，则在开发时会自动为您配置这些属性。
Thymeleaf模板
如果您使用Thymeleaf，请将spring.thymeleaf.cache设置为false。有关其他Thymeleaf定制选项，请参见ThymeleafAutoConfiguration。
FreeMarker模板
如果使用FreeMarker，请设置spring.freemarker.cache为false。有关其他FreeMarker定制选项，请参见FreeMarkerAutoConfiguration。
Groovy模板
如果使用Groovy模板，请设置spring.groovy.template.cache为false。请参阅GroovyTemplateAutoConfiguration以获取其他Groovy定制选项。
9.15.3。快速应用重启
spring-boot-devtools模块包括对应用程序自动重启的支持。尽管不如JRebel这样的技术快，但通常比“冷启动”要快得多。在研究本文档后面讨论的一些更复杂的重载选项之前，您可能应该先尝试一下。
9.15.4。重新加载Java类而无需重新启动容器
许多现代的IDE（Eclipse，IDEA等）都支持字节码的热交换。因此，如果所做的更改不影响类或方法的签名，则应干净地重新加载而没有副作用。
9.16。Build
Spring Boot包括Maven和Gradle的构建插件。本部分回答有关这些插件的常见问题。
9.16.1。生成构建信息
Maven插件和Gradle插件都允许生成包含项目的坐标，名称和版本的构建信息。还可以将插件配置为通过配置添加其他属性。当存在这样的文件时，Spring Boot会自动配置一个BuildProperties bean。
要使用Maven生成构建信息，请为build-info目标添加执行，如以下示例所示：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.2.0.RELEASE</version>
<executions>
<execution>
<goals>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
有关更多详细信息，请参见Spring Boot Maven插件文档。
下面的示例对Gradle执行相同的操作：
springBoot {
buildInfo()
}
有关更多详细信息，请参见Spring Boot Gradle插件文档。
9.16.2。生成Git信息
Maven和Gradle都允许生成一个git.properties文件，其中包含有关git构建项目时源代码存储库状态的信息。
对于Maven用户，spring-boot-starter-parent POM包含一个预配置的插件来生成git.properties文件。要使用它，请将以下声明添加到您的POM中：
<build>
<plugins>
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
</plugin>
</plugins>
</build>
Gradle用户可以通过使用gradle-git-properties插件获得相同的结果，如以下示例所示：
plugins {
id "com.gorylenko.gradle-git-properties" version "1.5.1"
}
git.properties内的提交时间应与以下格式匹配：yyyy-MM-dd’T’HH:mm:ssZ。这是上面列出的两个插件的默认格式。使用此格式，可以将时间解析为Date，并将其序列化为JSON时的格式由Jackson的日期序列化配置设置控制。
9.16.3。自定义依赖版本
如果您使用直接或间接继承自spring-boot-dependencies（例如spring-boot-starter-parent）的Maven构建，但要覆盖特定的第三方依赖关系，则可以添加适当的<properties>元素。浏览spring-boot-dependencies POM以获取属性的完整列表。例如，要选择其他slf4j版本，可以添加以下属性：
<properties>
<slf4j.version>1.7.5<slf4j.version>
</properties>
仅当您的Maven项目从spring-boot-dependencies（直接或间接）继承时，此方法才有效。如果您添加了spring-boot-dependencies在dependencyManagement部分的<scope>import</scope>，则必须自己重新定义工件，而不是覆盖属性。
每个Spring Boot版本都是针对这组特定的第三方依赖关系进行设计和测试的。覆盖版本可能会导致兼容性问题。
要覆盖Gradle中的依赖版本，请参阅Gradle插件文档的这一部分。
9.16.4。使用Maven创建可执行JAR
spring-boot-maven-plugin可用于创建可执行的JAR。如果使用spring-boot-starter-parent POM，则可以声明插件，然后将jar重新包装如下：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
如果您不使用父POM，则仍然可以使用该插件。但是，您必须另外添加一个<executions>部分，如下所示：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.2.0.RELEASE</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
有关完整用法的详细信息，请参阅插件文档。
9.16.5。使用Spring Boot应用程序作为依赖项
像war文件一样，Spring Boot应用程序也不打算被用作依赖项。如果您的应用程序包含要与其他项目共享的类，则建议的方法是将该代码移到单独的模块中。然后，您的应用程序和其他项目可以依赖单独的模块。
如果您不能按照上面的建议重新排列代码，则必须配置Spring Boot的Maven和Gradle插件以生成一个单独的工件，该工件适合用作依赖项。可执行档案不能用作依赖项，因为可执行jar格式将打包应用程序类到BOOT-INF/classes中。这意味着当将可执行jar用作依赖项时，找不到它们。
为了产生两个工件，一个可以用作依赖项，另一个可以执行，必须指定分类器。该分类器应用于可执行归档文件的名称，保留默认归档文件以用作依赖项。
要在Maven中配置exec分类器，可以使用以下配置：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<classifier>exec</classifier>
</configuration>
</plugin>
</plugins>
</build>
9.16.6。运行可执行jar时提取特定的库
可执行jar中的大多数嵌套库不需要解压即可运行。但是，某些库可能会有问题。例如，JRuby包含自己的嵌套jar支持，它假定jruby-complete.jar总是可以直接以文件的形式直接使用。
为了处理任何有问题的库，您可以标记在可执行jar首次运行时应自动解压缩特定的嵌套jar。这些嵌套的jar会写在system属性java.io.tmpdir标识的临时目录下。
应注意确保已配置您的操作系统，以便在应用程序仍在运行时，它不会删除已解压缩到临时目录中的jar。
例如，为了指示应该使用Maven插件将JRuby标记为要解包，您可以添加以下配置：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<requiresUnpack>
<dependency>
<groupId>org.jruby</groupId>
<artifactId>jruby-complete</artifactId>
</dependency>
</requiresUnpack>
</configuration>
</plugin>
</plugins>
</build>
9.16.7。创建带有排除项的不可执行的JAR
通常，如果您具有一个可执行和一个不可执行的jar作为两个单独的构建产品，则可执行版本具有库jar中不需要的其他配置文件。例如，application.yml配置文件可能被排除在不可执行的JAR中。
在Maven中，可执行jar必须是主要工件，您可以为库添加一个分类的jar，如下所示：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>lib</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>lib</classifier>
<excludes>
<exclude>application.yml</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
9.16.8。使用Maven远程调试Spring Boot应用程序
要将远程调试器附加到使用Maven启动的Spring Boot应用程序，可以使用maven plugin的jvmArguments属性。
9.16.9。在不使用spring-boot-antlib的情况下从Ant构建可执行存档
要使用Ant进行构建，您需要获取依赖项，进行编译，然后创建一个jar或war存档。要使其可执行，可以使用spring-boot-antlib模块，也可以按照以下说明进行操作：
- 如果要构建jar，请将应用程序的类和资源打包到嵌套BOOT-INF/classes目录中。如果要构建war，请照常将应用程序的类打包在嵌套WEB-INF/classes目录中。
- 在嵌套的
BOOT-INF/libjar或WEB-INF/libwar目录中添加运行时依赖项。切记不要压缩存档中的条目。 - 将provided（嵌入式容器）依赖项添加到jar中的嵌套目录
BOOT-INF/lib或war中的WEB-INF/lib-provided。切记不要压缩存档中的条目。 - 将
spring-boot-loader类添加到存档的根目录（以便Main-Class可用）。 - 使用适当的启动器（例如jar文件的
JarLauncher）作为清单中的Main-Class属性，并指定其所需的其他属性作为清单条目（主要是通过设置Start-Class属性）。
以下示例显示了如何使用Ant构建可执行归档文件：
<target name="build" depends="compile">
<jar destfile="target/${ant.project.name}-${spring-boot.version}.jar" compress="false">
<mappedresources>
<fileset dir="target/classes" />
<globmapper from="*" to="BOOT-INF/classes/*"/>
</mappedresources>
<mappedresources>
<fileset dir="src/main/resources" erroronmissingdir="false"/>
<globmapper from="*" to="BOOT-INF/classes/*"/>
</mappedresources>
<mappedresources>
<fileset dir="${lib.dir}/runtime" />
<globmapper from="*" to="BOOT-INF/lib/*"/>
</mappedresources>
<zipfileset src="${lib.dir}/loader/spring-boot-loader-jar-${spring-boot.version}.jar" />
<manifest>
<attribute name="Main-Class" value="org.springframework.boot.loader.JarLauncher" />
<attribute name="Start-Class" value="${start-class}" />
</manifest>
</jar>
</target>
9.17。传统部署
Spring Boot支持传统部署以及更现代的部署形式。本节回答有关传统部署的常见问题。
9.17.1。创建可部署的war文件
由于Spring WebFlux不严格依赖Servlet API，并且默认情况下将应用程序部署在嵌入式Reactor Netty服务器上，因此WebFlux应用程序不支持War部署。
生成可部署war文件的第一步是提供一个SpringBootServletInitializer子类并覆盖其configure方法。这样做利用了Spring Framework的Servlet 3.0支持，并允许您在由Servlet容器启动应用程序时对其进行配置。通常，应将应用程序的主类更新为继承SpringBootServletInitializer，如以下示例所示：
@SpringBootApplication
public class Application extends SpringBootServletInitializer {
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(Application.class);
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
下一步是更新构建配置，以使您的项目生成war文件而不是jar文件。如果您使用Maven和spring-boot-starter-parent（为您配置Maven的war插件），那么您要做的就是修改pom.xml以将包装更改为war，如下所示：
<packaging>war</packaging>
如果使用Gradle，则需要进行修改，build.gradle以将war插件应用于项目，如下所示：
apply plugin: 'war'
该过程的最后一步是确保嵌入式servlet容器不干扰war文件所部署到的servlet容器。为此，您需要将嵌入式Servlet容器依赖性标记为已提供。
如果使用Maven，则以下示例将servlet容器（在本例中为Tomcat）标记为已提供：
<dependencies>
<!-- … -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
<!-- … -->
</dependencies>
如果使用Gradle，则以下示例将servlet容器（在本例中为Tomcat）标记为已提供：
dependencies {
// …
providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
// …
}
providedRuntime比Gradle的compileOnly配置更可取。除其他限制外，compileOnly依赖项不在测试类路径上，因此任何基于Web的集成测试都将失败。
如果您使用Spring Boot构建工具，则将提供的嵌入式servlet容器依赖关系标记为provided将生成可执行的war文件，并将提供的依赖关系打包在lib-provided目录中。这意味着，除了可以部署到servlet容器之外，还可以通过java -jar在命令行上使用运行应用程序。
9.17.2。将现有应用程序转换为Spring Boot
对于非Web应用程序，将现有的Spring应用程序转换为Spring Boot应用程序应该很容易。为此，请丢弃您的创建ApplicationContext代码，并用SpringApplication或SpringApplicationBuilder调用替换它。Spring MVC Web应用程序通常适合于首先创建可部署的war应用程序，然后再将其迁移到可执行的war或jar。请参阅有关将jar转换为war的入门指南。
要通过扩展SpringBootServletInitializer（例如，在名为Application的类中）并添加Spring Boot的@SpringBootApplication注释来创建可部署的war，请使用类似于以下示例所示的代码：
@SpringBootApplication
public class Application extends SpringBootServletInitializer {
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
// Customize the application or call application.sources(...) to add sources
// Since our example is itself a @Configuration class (via @SpringBootApplication)
// we actually don't need to override this method.
return application;
}
}
请记住，无论您放置什么在sources里，都只是Spring ApplicationContext。通常，任何已经起作用的东西都应该在这里工作。可能有些bean可以在以后删除，并让Spring Boot为它们提供自己的默认值，但是在你需要这么做之前，应该可以使其正常工作，然后再执行此操作。
可以将静态资源移到类路径根目录中/public（或/static或/resources或/META-INF/resources）。这同样适用于messages.properties（Spring Boot自动在类路径的根目录中检测到）。
在Spring 和Spring Security中使用Vanilla DispatcherServlet不需要进一步更改。如果您的应用程序具有其他功能（例如，使用其他servlet或过滤器），则可能需要通过从web.xml中替换这些元素来为上下文添加一些配置，如下所示：
Servlet或ServletRegistrationBean类型的@Bean将安装Bean在容器中，好像它是web.xml中的一个<servlet/>与<servlet-mapping/>。Filter或FilterRegistrationBean类型的@Bean，表现得类似（作为<filter/>和<filter-mapping/>）。- 一个XML文件中的ApplicationContext可以通过
@ImportResource被添加在你的Application中。另外，一些简单的情况下，注解配置已被大量使用可以在几行中作为@Bean定义重新创建。
war文件运行后，可以通过向Application中添加一个main方法使其变为可执行文件，如以下示例所示：
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
如果打算以war或可执行应用程序的形式启动应用程序，则需要使用对SpringBootServletInitializer回调函数可用的方法和main类似于以下类的方法共享构建器的自定义项：
@SpringBootApplication
public class Application extends SpringBootServletInitializer {
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
return configureApplication(builder);
}
public static void main(String[] args) {
configureApplication(new SpringApplicationBuilder()).run(args);
}
private static SpringApplicationBuilder configureApplication(SpringApplicationBuilder builder) {
return builder.sources(Application.class).bannerMode(Banner.Mode.OFF);
}
}
应用程序可以分为多个类别：
- 没有web.xml的Servlet 3.0+应用程序。
- 带有web.xml的应用程序。
- 具有上下文层次结构的应用程序。
- 没有上下文层次结构的应用程序。
所有这些都应该适合翻译，但是每种可能都需要稍微不同的技术。
如果Servlet 3.0+应用程序已经使用了Spring Servlet 3.0+初始化程序支持类，那么它们可能会很容易转换。通常，来自现有WebApplicationInitializer的所有代码都可以移入SpringBootServletInitializer。如果您现有的应用程序有多个ApplicationContext（例如，如果使用AbstractDispatcherServletInitializer），则可以将所有上下文源组合到一个SpringApplication中。您可能会遇到的主要并发症是，如果合并无效，则需要维护上下文层次结构。有关示例，请参见有关构建层次结构的条目。通常，需要拆分包含特定于Web的功能的现有父上下文，以便所有ServletContextAware组件都位于子上下文中。
还不是Spring应用程序的应用程序可以转换为Spring Boot应用程序，前面提到的指南可能会有所帮助。但是，您可能仍然遇到问题。在这种情况下，建议您使用spring-boot标记来在Stack Overflow上提问。
9.17.3。将WAR部署到WebLogic
要将Spring Boot应用程序部署到WebLogic，必须确保servlet初始化程序直接实现WebApplicationInitializer（即使从已经实现了它的基类扩展）。
WebLogic的典型初始化程序应类似于以下示例：
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;
import org.springframework.web.WebApplicationInitializer;
@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer implements WebApplicationInitializer {
}
如果使用Logback，则还需要告诉WebLogic首选打包版本，而不是服务器预先安装的版本。您可以通过添加WEB-INF/weblogic.xml具有以下内容的文件来做到这一点：
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app
xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
https://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd
http://xmlns.oracle.com/weblogic/weblogic-web-app
https://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>org.slf4j</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
</wls:weblogic-web-app>
9.17.4。使用Jedis代替Lettuce
默认情况下，Spring Boot启动器（spring-boot-starter-data-redis）使用Lettuce。您需要排除该依赖性，而改为包含Jedis。Spring Boot管理这些依赖关系，以帮助使此过程尽可能简单。
以下示例显示了如何在Maven中执行此操作：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
<exclusions>
<exclusion>
<groupId>io.lettuce</groupId>
<artifactId>lettuce-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
</dependency>
以下示例显示了如何在Gradle中执行此操作：
configurations {
compile.exclude module: "lettuce"
}
dependencies {
compile("redis.clients:jedis")
// ...
}
