一般认为,SpringBoot 微框架从两个主要层面影响 Spring 社区的开发者们:
基于 Spring 框架的“约定优先于配置”理念以及最佳实践之路。提供了针对日常企业应用研发各种场景的 spring-boot-starter 自动配置依赖模块,如此多“开箱即用”的依赖模块,使得开发各种场景的 Spring 应用更加快速和高效。Java 的日志系统多种多样,从 java.util 默认提供的日志支持,到 log4j,log4j2,commons logging 等,复杂繁多
在 maven pom文件中添加了 spring-boot-starter-logging 那么,我们的 SpringBoot 应用将自动使用 logback 作为应用日志框架,SpringBoot 启动的时候,由 LoggingApplicationListener 根据情况初始化并使用。
SpringBoot 为我们提供了很多默认的日志配置,只要将 spring-boot-starter-logging 作为依赖加入到当前应用的 classpath,则“开箱即用”,不需要做任何多余的配置。
但假设我们要对默认 SpringBoot 提供的应用日志设定做调整,则可以通过几种方式进行配置调整:
遵循 logback 的约定,在 classpath 中使用自己定制的 logback.xml 配置文件。(推荐)在文件系统中任何一个位置提供自己的 logback.xml 配置文件,然后通过 logging.config 配置项指向这个配置文件来启用它,比如在 application.properties 中指定如下的配置。 logging.config=/…/xx.xml将 spring-boot-starter-web 加入项目的 maven pom中 我们就得到了一个直接可执行的 Web 应用,当前项目下运行 mvn spring-boot:run 就可以直接启动一个使用了嵌入式 tomcat 服务请求的 Web 应用
只不过我们还没有提供任何服务 Web 请求的 Controller,所以访问任何路径都会返回一个 SpringBoot 默认提供的错误页面(一般称其为 whitelabel error page)
我们可以在当前项目下新建一个服务根路径 Web 请求的 Controller 实现: 重新运行 mvn spring-boot:run 并访问 http://localhost:8080 错误页面将被我们的 Controller 返回的消息所替代,一个简单的 Web 应用就这样完成了。
但是,简单的背后,其实却有很多“潜规则”(约定),我们只有充分了解了这些“潜规则”,才能更好地应用 spring-boot-starter-web。
项目结构层面与传统打包为 war 的 Java Web 应用的差异在于,静态文件和页面模板的存放位置变了 原来是放在 src/main/webapp 目录下的一系列资源, 现在都统一放在 src/main/resources 相应子目录下,比如:
src/main/resources/static 用于存放各类静态资源,比如 css,js 等。src/main/resources/templates 用于存放模板文件,比如 *.vm。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 的相关配置,自己完全重新配置。