Spring Boot 为Spring生态系统带来了一种自以为是的方法。首先于2014年中发布。Spring Boot已经经过了很多的发展和改进。它的Spring Boot 2.0版今天准备在2018年初发布。
在这个受欢迎的图书馆试图帮助我们的地方有不同的领域:
在本文中,我们将探讨为Spring Boot 2.0计划的一些更改和功能。我们还会描述这些变化如何帮助我们提高生产力。
Spring Boot 2.x将不再支持Java 7及更低版本,因此Java 8是最低要求。
它也是第一个支持Java 9的版本。没有计划在1.x分支上支持Java 9。这意味着如果你想使用最新的Java版本并利用这个框架,Spring Boot 2.x是你唯一的选择。
随着Spring Boot的每个新版本的发布,Java生态系统的各种依赖关系的版本都得到升级。
在2.x中,这也不例外。列出它们是没有意义的,但我们可以看看spring-boot-dependencies.pom,以查看在任何给定时间点使用的版本。
有关最低要求版本的一些要点:
Gradle插件已经通过重大改进和一些突破性更改。
要创建胖罐,bootRepackage Gradle的任务将被bootJar和bootWar分别替换为jar和war。
如果我们想在1.x中使用Gradle插件运行我们的应用程序,我们可以执行gradle bootRun。 在Spring Boot 2.x bootRun中扩展了Gradle的JavaExec。这意味着我们可以更容易地使用我们通常在传统JavaExec任务中使用的相同配置来配置它。
有时我们发现自己想要利用Spring Boot BOM。但有时我们不想构建完整的引导应用程序或重新打包它。
在这方面,知道Spring Boot 2.x默认不再应用依赖管理插件是很有趣的。
如果我们想要Spring Boot依赖管理,我们应该添加:
apply plugin: 'io.spring.dependency-management'
这在上述场景中以较少的配置给予我们更大的灵活性。在Spring Boot 2.x中,安全配置得到极大的简化。默认情况下,一切都是安全的,包括静态资源和执行器端点。
一旦用户明确配置安全性,Spring Boot的默认设置将停止影响。用户可以在一个地方配置所有访问规则。
这将阻止我们与WebSecurityConfigurerAdapter排序问题纠缠在一起。这些问题通常在以自定义方式配置Actuator和App安全规则时发生。
让我们来看看混合执行器和应用程序规则的简单安全片段:
http.authorizeRequests()
.requestMatchers(EndpointRequest.to("health"))
.permitAll() // Actuator rules per endpoint
.requestMatchers(EndpointRequest.toAnyEndpoint())
.hasRole("admin") // Actuator general rules
.requestMatchers(StaticResourceRequest.toCommonLocations())
.permitAll() // Static resource security
.antMatchers("/**")
.hasRole("user") // Application security rules
// ...
更多spring security 使用讲解点击这篇博客spring boot 2.0 security 5.0 整合入门
Spring Boot 2为不同的反应模块带来了一套新的启动器。一些例子是WebFlux,以及MongoDB,Cassandra或Redis的反应对象。
还有WebFlux的测试工具。特别是,我们可以利用@WebFluxTest。这与最初作为1.4.0中各种测试片的一部分引入的旧版@WebMvcTest类似。
Spring Boot带来了一些有用的工具,使我们能够创建可用于生产的应用程序。除此之外,我们可以利用Spring Boot Actuator。
执行器包含用于简化监控,追踪和一般应用内省的各种工具。关于执行器的更多细节可以在我们以前的文章中找到。
凭借其2版本执行器已经通过重大改进。这个迭代着重于简化定制。它还支持其他网络技术,包括新的反应模块。
在Spring Boot 1.x中,只有Spring-MVC支持执行器端点。然而,在2.x中,它变得独立和可插入。Spring Boot现在为WebFlux,Jersey和Spring-MVC带来了支持。
和以前一样,JMX仍然是一个选项,可以通过配置启用或禁用。
新的执行器基础设施与技术无关。正因为如此,开发模式从头开始重新设计。
新模式也带来更大的灵活性和表现力。
我们来看看如何为执行器创建一个水果端点:
@Endpoint(id = "fruits")
public class FruitsEndpoint {
@ReadOperation
public Map<String, Fruit> fruits() { ... }
@WriteOperation
public void addFruits(@Selector String name, Fruit fruit) { ... }
}
一旦我们在我们的ApplicationContext中注册了FruitsEndpoint ,它就可以使用我们选择的技术作为Web端点公开。我们也可以通过JMX公开它,具体取决于我们的配置。
将我们的端点转换为Web端点将导致:
还有更多的可能性。我们可以检索更多粒度数据。另外,我们可以为每种底层技术定义特定的实现(例如,JMX和Web)。为了本文的目的,我们将把它作为一个简单的介绍,而不会涉及太多细节。
在Spring Boot 1.x Actuator中定义了自己的安全模型。这个安全模型与我们的应用程序使用的安全模型不同。
当用户试图提升安全性时,这是许多痛点的根源。
在2.x中,应该使用与应用程序其余部分相同的配置来配置安全配置。
默认情况下,大多数执行器端点被禁用。这与Spring Security是否在类路径中无关。除了状态和信息之外,所有其他端点都需要由用户启用。
Spring引入了1.3中的devtools。
它负责平滑典型的发展问题。例如,视图技术的缓存。它还执行自动重新启动和浏览器实时重新加载。此外,它使我们能够远程调试应用程序。
在2.x中,当我们的应用程序被devtools重新启动时,“delta”报告将被打印出来。本报告将指出哪些变化及其对我们的应用程序可能产生的影响。
假设我们定义一个JDBC数据源来覆盖Spring Boot配置的JDBC数据源。
D evtools将指示自动配置的那个不再被创建。它还会指出原因,即对于类型为javax.sql.DataSource的@ConditionalOnMissingBean中的不良匹配。D evtools将在执行重新启动后打印此报告。
由于JDK 9的问题,devtools不再支持通过HTTP进行远程调试。
在本文中,我们介绍了Spring Boot 2将带来的一些变化。
我们讨论了依赖关系以及Java 8如何成为最低支持版本。
接下来,我们谈到了自动配置。我们专注于安全性。我们还谈到了执行器和它所获得的许多改进。
最后,我们谈到了在提供的开发工具中发生的一些小的调整。
https://www.leftso.com/article/443.html