直接引用静态资源不行的,你要把静态资源也做成web服务。
换言之,你自己在浏览器里面能正常访问静态资源,且不能出现404
比如百度首页上引入css,
网页链接
人家这个css能通过浏览器正常访问的,所以你这个跟springboot没啥关系,是web配置的问题
在做文件上传的过程中,文件会被集中的上传到服务器的某一个目录下,上传完之后,在前台页面就需要回显,那么如果能映射到文件呢,之前我的做法是,前端根据文件id调用后台接口,然后后台返回一个完整的文件地址,这样做会暴露真实的路径地址,非常的不安全,其实还有个更好的方法就是做静态资源文件的映射,如下:
file-setting 勾选项目自动构建
2
使用快捷键 ctrl+ shift+ alt + / 勾选复选框后重启,就可以了 目前以lib后缀的库有两种,一种为静态链接库(Static Libary,以下简称“静态库”),另一种为动态连接库
事情是这样的, 最近接手个项目 给它底层从ssm整到springboot2 + mp
由于之前很多xxxdo请求 而我又不想用后缀,
所以就得匹配全部后缀或者无后缀(方法有很多方案自行百度), 然后就狗血的出现了一个问题
继续跟踪
说明实在这一行确定请求的类型的 发现它调用了getHandler方法 继续跟
! 注意 我这里形参的参数类型写的是我自己写的MyDispatcherServlet 这样就能注册上了
假设有一个jar包,里面有一个testtxt,里面有一行字符串 123abc ,现在要在一个以jar命令运行的spring-boot项目环境中读取,要怎么做?
假设把这个jar包,一个放到D盘的test目录下,一个放到spring-boot项目resources目录下的lib子目录里,可以使用以下两种方法分别读取:
使用mvn clean package打包项目,然后使用java -jar xxxjar执行该项目文件,观察日志文件就会发现,两种方式都成功了:
Springboot 读取配置文件(applicationyaml, applicationproperties)的过程发生在SpringApplication#prepareEnvironment() 阶段,而prepareEnvironment又属于整个Springboot 应用启动的非常前置阶段,因为Environment的准备是后续bean创建的基础。让我们来一探启动是的详细code。除去StopWatch这些code,可以发现prepareEnvironment 发生在SpringApplication#run 这在整个应用启动的多步实质性 *** 作中几乎是第一步。
而prepareEnvironment中最重要的是通过触发listener(EventPublishingRunListener)来通过SimpleApplicationEventMulticaster#multicastEvent发出ApplicationEnvironmentPreparedEvent。
而SimpleApplicationEventMulticaster#multicastEvent的实现其实也很简单,找到相关的监听ApplicationEnvironmentPreparedEvent的listener,然后一个个的调用他们的Listener#onApplicationEvent(event)方法,而这其中就包括了处理configuration文件的listener。
在Springboot 240 之前这个处理configuration 文件的lister是ConfigFileApplicationListener,在240之后,处理configuration 文件的lister是EnvironmentPostProcessorApplicationListener,并且对configuration文件的加载做了较大的改变,导致一些行为可能出现了变化,这也就是下面要详细讲的内容。
Springboot 240之后,configuration 文件的load顺序按照优先级是如下顺序(序号大的会被小的覆盖):
和之前版本比较,整体的属性加载顺序并无调整,只有Application properties(14,15)这里有顺序的调整,具体调整为:
如果存在多个active的profiles,例如[Test, Dev], 那么对于同时存在两个profile 配置文件中的配置,后面的profile里的配置(Dev)会覆盖前面profile(Test)里配置的值。
前面讲了这么多,终于要引出Springboot 24之后配置文件加载的行为变化了。
考虑这样的情况,如果我想在跑Springboot test的时候指定特定的profile,那么可以在Test class中加入@ActiveProfile("Test")。 如果我的应用中存在ApplicationEnvironmentPreparedEvent的某个自定义listener中,会根据当前environment 设置profile,如envaddActiveProfile("Dev")。
当前就会有两个active profile,由于springboot-test会在调用application#run 前利用DefaultActiveProfilesResolver把@ActiveProfile注解定义的profile(Test)先加入了active的profile,等test run的时候 envaddActiveProfile("Dev") 又会把"Dev"也作为active profile 加入,这时候当前的active profile便为["Test", "Dev"]。
据上面介绍,后面的profile(Dev)对应的configuration 会覆盖前面的(Test)。可Springboot 240之前的版本为我们做了调整,让Test class中@ActiveProfile内定义的profile所对应的配置文件成为最高优先级。
刚才提到在Springboot 240 之前这个处理configuration 文件的lister是ConfigFileApplicationListener,我们
来看看ConfigFileApplicationListener的相关code。
查看initializeProfiles(),发现此时对profile的顺序做了调整,将activatedViaProperty (Test) 放在最后add,于是profile的顺序就变成了[Dev, Test]。
在profilespoll()时原本profile的顺序已经倒了过来,已经变为[Dev, Test], 在load()方法中由于后置的Test profile,application-Testyaml中的值最终生效了。
可是到了Springboot240之后,ConfigFileApplicationListener被deprecated了,取而代之的是EnvironmentPostProcessorApplicationListener,EnvironmentPostProcessorApplicationListener通过调用ConfigDataEnvironmentPostProcessor来完成configuration加载。
EnvironmentPostProcessorApplicationListenerjava
ConfigDataEnvironmentPostProcessorjava
ConfigDataEnvironmentPostProcessor只是老老实实的set了active profile,并没有调换profile的顺序。最后调用定义在springfactories中的resource loader class来load 配置文件。
YamlPropertySourceLoaderjava
插一句,Springboot为我们提供了很好的yaml文件parse的code,当你需要解析yaml文件时不妨直接参考Springboot的YamlPropertySourceLoader
这样一旦应用升级到Springboot 240之后相同的test code会使用application-Devyaml中配置的值,造成了test结果的改变。
如果要解决这个问题,根据上面介绍的配置文件优先级顺序,可以在@SpringbootTest中设置properties 来作为最终的配置覆盖当前profile对应的配置。
了解一个框架很不容易,一个小小的变化都有可能造成应用的行为变化,唯有刨根问底,不断总结才是framework人解决一切问题的不变的方法论。
以上就是关于springboot spring.resources.static-locations引用外部静态资源全部的内容,包括:springboot spring.resources.static-locations引用外部静态资源、springboot静态资源文件的映射、springboot不打包静态文件等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)