Spring Boot(三) spring-boot-starter

Spring Boot是Spring框架的约定优于配置的实现,提供开箱即用的实现,这些实现都以spring-boot-starter-做前缀命名,都位于org.springframework.boot包或者命名空间下

配置方式有几类:

·命令行参数(Command Line Args)。

·系统环境变量(Environment Variables)。
·位于文件系统中的配置文件。
·位于classpath中的配置文件。
·固化到代码中的配置项。

以上几种方式按照优先级从高到低排列,高优先级方式提供的配置项可以覆盖或者优先生效,比如通过命令行参数传入的配置项会覆盖通过环境变量传入的同一配置项,当然也会覆盖其他后面几种方式给出的同一配置项。
不管是位于文件系统还是classpath,SpringBoot应用默认的配置文件名叫作application.properties,可以直接放在当前项目的根目录下或者名称为config的子目录下。

spring-boot-starter-logging

默认用的logback,可以更改为log4j和log4j2,在maven中声明类似spring-boot-starter-log4j的依赖即可

spring-boot-starter-web

自动配置springmvc和tomcat,默认run会在8080端口启动tomcat,并生成一个默认的错误页面

可以新建一个服务根路径的web请求的controller实现:

@RestControllerpublic class IndexController { @RequestMapping("/") public String index() { return "hello, there"; }} 重新运行mvn spring-boot:run并访问http://localhost:8080,错误页面将被我们的Controller返回的消息所替代,一个简单的Web应用就这样完成了。

  • web项目结构约定:

项目结构层面与传统打包为war的Java Web应用的差异在于,静态文件和页面模板的存放位置变了,原来是放在src/main/webapp目录下的一系列资源,现在都统一放在src/main/resources相应子目录下,比如:

1)src/main/resources/static用于存放各类静态资源,比如css,js等。

2)src/main/resources/templates用于存放模板文件,比如*.vm。

默认是jar形式的打包,可以改为war

  • SpringMVC框架约定:

spring-boot-starter-web默认将为我们自动配置如下一些SpringMVC必要组件:

·必要的ViewResolver,比如ContentNegotiatingViewResolver和Bean-NameViewResolver。

·将必要的Converter、GenericConverter和Formatter等bean注册到IoC容器。

·添加一系列的HttpMessageConverter以便支持对Web请求和相应的类型转换。

·自动配置和注册MessageCodesResolver。

任何时候,如果我们对默认提供的SpringMVC组件设定不满意,都可以在IoC容器中注册新的同类型的bean定义来替换,或者直接提供一个基于WebMvcConfigurerAdapter类型的bean定义来定制,甚至直接提供一个标注了@EnableWebMvc的@Configuration配置类完全接管所有SpringMVC的相关配置,自己完全重新配置。

  • web容器约定

spring-boot-starter-web默认使用嵌入式tomcat作为web容器对外提供HTTP服务,默认将使用8080端口对外监听和提供服务:

1)假设我们不想使用默认的嵌入式tomcat(spring-boot-starter-tomcat自动配置模块),那么可以引入spring-boot-starter-jetty或者spring-boot-starter-undertow作为替代方案。

2)假设我们不想使用默认的8080端口,那么我们可以通过更改配置项server.port使用自己指定的端口,比如:

server.port=9000 spring-boot-starter-web提供了很多以server.为前缀的配置项用于对嵌入式Web容器提供配置,比如:

·server.port

·server.address

·server.ssl.*

·server.tomcat.*

如果这些依然无法满足需求,SpringBoot甚至允许我们直接对嵌入式的Web容器实例进行定制,这可以通过向IoC容器中注册一个EmbeddedServletContainerCustomizer类型的组件来对嵌入式Web容器进行定制:

public class UnveilSpringEmbeddedTomcatCustomizer implements Embed-dedServletContainerCustomizer { @Override public void customize(ConfigurableEmbeddedServletContainer container) { container.setPort(9999); container.setContextPath("/unveil-spring-chapter3"); // ... }} 再深入的定制则需要针对特定的嵌入式Web容器,使用实现对应的Factory并注册到IoC容器:

·TomcatEmbeddedServletContainerFactory

·JettyEmbeddedServletContainerFactory

·UndertowEmbeddedServletContainerFactory

 

spring-boot-starter-jdbc

大部分Java应用都需要访问数据库,尤其是服务层,所以,SpringBoot会为我们自动配置相应的数据访问设施。

若想SpringBoot为我们自动配置数据访问的基础设施,那么,我们需要直接或者间接地依赖spring-jdbc,一旦spring-jdbc位于我们SpringBoot应用的classpath,即会触发数据访问相关的自动配置行为,最简单的做法就是把spring-boot-starter-jdbc加为应用的依赖。

默认情况下,如果我们没有配置任何DataSource,那么,SpringBoot会为我们自动配置一个基于嵌入式数据库的DataSource,这种自动配置行为其实很适合于测试场景,但对实际的开发帮助不大,基本上我们会自己配置一个DataSource实例,或者通过自动配置模块提供的配置参数对DataSource实例进行自定义的配置。

假设我们的SpringBoot应用只依赖一个数据库,那么,使用DataSource自动配置模块提供的配置参数是最方便的:

spring.datasource.url=jdbc:mysql://{database host}:3306/{databaseName}spring.datasource.username={database username}spring.datasource.password={database password} 当然,自己配置一个DataSource也是可以的,SpringBoot也会智能地选择我们自己配置的这个DataSource实例(只不过必要性真不大)。

除了DataSource会自动配置,SpringBoot还会自动配置相应的JdbcTemplate、DataSourceTransactionManager等关联“设施”,可谓服务周到,我们只要在使用的地方注入就可以了:

class SomeDao { @Autowired JdbcTemplate jdbcTemplate; public <T> List<T> queryForList(String sql){ // ... } // ...} 不过,spring-boot-starter-jdbc以及与其相关的自动配置也不总是带来便利,在某些场景下,我们可能会在一个应用中需要依赖和访问多个数据库,这个时候就会出现问题了。

假设我们在ApplicationContext中配置了多个DataSource实例指向多个数据库:

@Beanpublic DataSource dataSource1() throws Throwable { DruidDataSource dataSource = new DruidDataSource(); dataSource.setUrl(...); dataSource.setUsername(...); dataSource.setPassword(...); // TODO other settings if necessary in the future. return dataSource;}@Beanpublic DataSource dataSource2() throws Throwable { DruidDataSource dataSource = new DruidDataSource(); dataSource.setUrl(...); dataSource.setUsername(...); dataSource.setPassword(...); // TODO other settings if necessary in the future. return dataSource;} 那么,不好意思,启动SpringBoot应用的时候会抛出类似如下的异常(Exception):

Exception):No qualifying bean of type [javax.sql.DataSource] is defined: expected single matching bean but found 2 为了避免这种情况的发生,我们需要在SpringBoot的启动类上做点儿“手脚”:

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class, DataSourceTransactionManagerAutoConfiguration.class})public class UnveilSpringChapter3Application { public static void main(String[] args) { SpringApplication.run(UnveilSpringChapter3Application.class, args); }} 也就是说,我们需要在这种场景下排除掉对SpringBoot默认提供的DataSource相关的自动配置。

但如果我们还是想要享受SpringBoot提供的自动配置DataSource的机能,也可以通过为其中一个DataSource配置添加org.springframework.context.annotation.Primary这个Annotation的方式以实现两全其美:

@Bean@Primarypublic DataSource dataSource1() throws Throwable { DruidDataSource dataSource = new DruidDataSource(); dataSource.setUrl(...); dataSource.setUsername(...); dataSource.setPassword(...); // TODO other settings if necessary in the future. return dataSource;}@Beanpublic DataSource dataSource2() throws Throwable { DruidDataSource dataSource = new DruidDataSource(); dataSource.setUrl(...); dataSource.setUsername(...); dataSource.setPassword(...); // TODO other settings if necessary in the future. return dataSource;} 另外,SpringBoot还提供了很多其他数据访问相关的自动配置模块,比如spring-boot-starter-data-jpa、spring-boot-starter-data-mongodb等,大家可以根据自己数据访问的具体场景选择使用这些自动配置模块。

警告 如果选择了spring-boot-starter-data-jpa等关系数据库相关的数据访问自动配置模块,并且还需要同时依赖访问多个数据库,那么,也需要相应的在SpringBoot启动类中排除掉这些自动配置模块中的AutoConfiguration实现类(对应spring-boot-starter-data-jpa是JpaRepositoriesAutoConfiguration),或者标注某个DataSource为@Primary。

spring-boot-starter-aop

如今,AOP(Aspect Oriented Programming)已经不是什么崭新的概念了,在经历了代码生成、动态代理、字节码增强甚至静态编译等不同时代的洗礼之后,Java平台上的AOP方案基本上已经以SpringAOP结合AspectJ的方式稳固下来(虽然大家依然可以自己通过各种字节码工具偶尔“打造一些轮子”)。

原则上来说,我们只要引入Spring框架中AOP的相应依赖就可以直接使用Spring的AOP支持了,不过,为了进一步为大家使用SpringAOP提供便利,SpringBoot还是“不厌其烦”地为我们提供了一个spring-boot-starter-aop自动配置模块。

spring-boot-starter-aop自动配置行为由两部分内容组成:

1)位于spring-boot-autoconfigure的org.springframework.boot.autoconfigure.aop.AopAutoConfiguration提供@Configuration配置类和相应的配置项。

2)spring-boot-starter-aop模块自身提供了针对spring-aop、aspectjrt和aspectjweaver的依赖。

一般情况下,只要项目依赖中加入了spring-boot-starter-aop,其实就会自动触发AOP的关联行为,包括构建相应的AutoProxyCreator,将横切关注点织入(Weave)相应的目标对象等,不过AopAutoConfiguration依然为我们提供了可怜的两个配置项,用来有限地干预AOP相关配置:

·spring.aop.auto=true

·spring.aop.proxy-target-class=false

对我们来说,这两个配置项的最大意义在于:允许我们投反对票,比如可以选择关闭自动的aop配置(spring.aop.auto=false),或者启用针对class而不是interface级别的aop代理(aop proxy)。

spring-boot-starter-security

主要面向web安全,配合spring-boot-starter-web

默认提供一个基于HTTP的Basic认证,可以对用户密码进行配置

security.user.name=xxx

security.user.password=xxx

还默认启动一些web安全防护,如XSS、CSRF等常见web攻击

SpringSecurity框架包括了基本的认证和授权,也提供了加密解密,统一登录等支持

AuthenticationManager/ AccessDecisionManager/ AbstractSecurityInterceptor是核心

AuthenticationManager管理身份认证,AccessDecisionManager控制放行,AbstractSecurityInterceptor是关卡的抽象

SpringSecurity基于Servlet规范,所以Play等不基于Servlet规范的框架无法使用

有多个filter,整体有三类:信道与状态管理、web安全防护类,认证和授权类

默认的filter序列间隔步长为10,所以可以在中间自定义filter

spring-boot-starter-actuator

用于SpringBoot应用的监控。内部默认提供了很多endpoint。

“监”抽象为Sensor类,“控”抽象为Actuator类。每类都有很多内置的endpoint。

Sensor类包括autoconfig、beans、configprops、info、health、env、metrics、trace、mapping

Actuator类包括shutdown(慎用)、dump

建议使用的方式是全部禁用,然后按需开启

health默认提供了数据源、磁盘空间、redis、solr、mongo等监控

 

 

 

 

转载于:https://my.oschina.net/bigsloth/blog/754495

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值