搬砖小抄

@EnableOAuth2Sso注解的源码

1
2
3
4
5
6
7
8
9
10

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@EnableOAuth2Client
@EnableConfigurationProperties(OAuth2SsoProperties.class)
@Import({ OAuth2SsoDefaultConfiguration.class, OAuth2SsoCustomConfiguration.class,
		ResourceServerTokenServicesConfiguration.class })
public @interface EnableOAuth2Sso {

}

它解决的问题：

• 拦截未授权请求：如果用户没有登录，引导用户（去认证服务器）做登录认证
• (去认证服务器)获取用户的身份信息

对于后端渲染页面视图的Web项目，只需要加上这个注解，即可实现OAuth2接入，无需编写登录页面。如果是前后端分离项目，由于后端不能控制页面跳转，需要前端辅助完成授权码获取，并传递给后端完成后续认证流程。

在代码中引用项目信息可以带来很多便利性，比如下面这个日志配置文件的代码片段(logback-spring.xml)

1
2
3

<configuration debug="false" scan="false">
	<property name="log-path" value="/var/logs/${project.artifactId}"/>
</configuration>	

这样，日志的路径跟Maven项目的artifactId就关联上了(Gradle项目也一样)，有利于统一管理，新项目直接把这个日志配置模版拷贝过期就行了。

此外，你也可以在application.yml中访问这些属性，比如

1
2

app.encoding: @project.build.sourceEncoding@
app.java.version: @java.version@

git 练级过程中的必备基础技能，比如:

• 全局配置
• 本地打包
• 分支(branch)操作
• 子模块操作
• 合并提交历史

ubuntu 16 是通过修改/etc/network/interfaces来配置网络接口信息，ubuntu 18 网络配置工具换成了netplan，对应的配置文件也换成了/etc/netplan/*.yaml。

Spring data 把数据库常见操作都封装得差不多了,甚至连分页都为不用自己写代码,确实大大提高了码砖的效率,对于一般的需求,往Reposistory里加几个接口就妥当了.那么反过来说,如果有’不一般’的需求呢?

这就是矛盾的地方,ORM用它自己的一套概念给程序员洗脑,让你感觉不到数据库的存在,但实际上要达到这个目标很难,总归要和数据库直接打交道.

我最近碰到的一个问题就是索引失效,这个问题一开始我还没察觉到,因为我已经提前根据查询语句创建了好了索引,但是当我观察数据库的性能报告却发现查询效率很低,把相应的语句弄出来执行EXPLAIN,居然是ALL.

如果你想拥有一个的私有GIT服务器,那么gitlab可能就是你唯一的选择了,正好我就有这样一个需求,我花了一些时间了解了一下它,然后真的感觉”它就是我的菜!”,并且有很多因素会使我难以拒绝:

• 稳定,功能强大: 我要的不仅仅是一个代码仓库,那样的话SVN也能将就用了.我需要的一个能够帮助我围绕代码来展开工作的全栈方案.
• 活跃: 开源的软件最怕就是作者丢个代码上去然后就跑了.有些新功能你可能现在用不上,但是在你需要的时候,你直接就用上成熟方案了,比如对kubernetes的支持.
• 一站式解决方案: 它不仅可以做问题跟踪,还可以做项目管理,并且它有自己的CI插件,从开发到部署都可以打通.
• 其他: 比如囊中羞涩,又比如老板信不过云服务托管商…

Spring Cloud Stream Reference Guide(Ditmars.RELEASE)的阅读笔记
相关内容

• 第四章:绑定器(Binder)
• 第五章:配置选项

文档中到处都有Binding和Binder这两个概念,一开始觉得有点晕头转向,推敲之后发现:

• Binding 指绑定的过程,和Binding有关参数就是在执行绑定过程中需要用到的参数.
• Binder 指执行绑定过程的对象,如Rabbit Binder,Kafka Binder.

AMQP 0-9-1 Model Explained读后感.
之前对AMQP的很多概念比较模糊,直到读了RabbitMQ主页上这篇关于AMQP 0-9-1的文章,感觉清晰了很多.

一些总结

关于持久化

和持久化有关的有好几个对象:

• 交换机
• 队列
• 消息

应用程序一般会在启动时去声明交换机,启动后就认为交换机总是存在的,然而应用程序并不知道Broker重启了,这就导致期望使用的交换机不存在的情况.

正常情况下,用MQ传递业务数据肯定是希望Broker上的消息不会丢失,要达到这个目的,消息本身以及消息所处的队列都要有持久化能力.

故事是有两个Bean,分别是A和B

• B注入了A里面
• A有一个@PostConstruct方法methodA
• B有一个mehtodB方法,也是配置了拦截器的

症状就是在methodA调用mehtodB时,mehtodB的拦截器没有生效.