Spring ServiceLocator 介绍及应用

在 Spring 中应用 ServiceLocator 方式来获取 Spring Bean 的介绍参考了那么多,其实还是数官方的 ServiceLocatorFactoryBean JavaDoc 文档最言简意该了。Spring 的 ServiceLocator 仿佛用处不大,说到底就是类似于下方找寻某个 Spring Bean 一样:

ApplicationContext context = ...;
Service service = context.getBean(ServiceImpl.class);
Service service = context.getBean("myService");

只是有了 ServiceLocatorFactoryBean(它本质上就是一个 FactoryBean) 后我们不需要直接与 ApplicationContext 打交道,且多个的 Spring Bean 可以从相关的一个 FactoryBean 获得。下面用两个例子来演示(代码中刨去了 package 和 import 部分的代码)

一:实现类只有一个 Spring Bean 时

接口类 Parser(我们要定位就是它的实现类) 阅读全文 >>

Python 函数参数的拆解

本文为阅读 《Python Tricks: The Book》一书的 3.5 Function Argument Unpacking 的笔记与扩充理解。函数参数拆解是定义可变参数(VarArgs) *args 和 **kwargs 的反向特性。

*args 和 **kwars 是函数可定义一个形参来接收传入的不定数量的实参。

而这里的函数参数拆解是形参定义多个,在调用时只传入一个集合类型对象(带上 * 或 ** 前缀),如 list, tuple, dict, 甚至是 generator, 然后函数能自动从集合对象中取得对应的值。

如果能理解下面赋值时的参数拆解和 Python 3.5 的新增 * ** 操作,那么于本文讲述的特性就好理解了。

唯一的不同时作为参数的集合传入函数时必须前面加上 * 或 **, 以此宣告该参数将被拆解,而非一个整体作为一个函数参数。加上 * 或 ** 与 Java 的 @SafeVarargs 有类似的功效,最接近的是 Scala 的 foo(Array[String]("d", "e") : _*) 写法。参见:Java 和 Scala 调用变参的方式 阅读全文 >>

Python 包管理及虚拟环境的应用(三: pipenv)

前两篇分别学习了 Python 如何进行依赖的管理,以及结合虚拟环境来使用 pip 进行依赖管理。而有人觉得把 virtualenv 与 pip 分开来操作太麻烦了,而且 requirements.txt 描述依赖的方式十分笨拙,所以在前两者之上创建了 pipenv, 也谈不上重新发明了轮子吧。

3. Pipenv: 新一代依赖管理与虚拟环境

倘若不是经由 virtualenv, venv 而来到 pipenv,没有对比也就无法体会到 pipenv 的妙处的。pipenv 在总结了 virtualenv/venv 的缺点之后由 Kenneth Reitz 于 2017 年 1 月发布的新型 Python 依赖管理器。

  1. 它不再需要单独用 virtualenv 和 pip,只要一条命令 pipenv 完成所有的事
  2. 不用手动管理 requirements.txt 文件,而是由  pipenv 自动维护 Pipfile 和 Pipfile.lock 文件
  3. 自动创建虚拟环境,并且虚拟环境与项目文件分离
  4. 更详尽的依赖图(例如 pipenv graph),像 mvn dependency:tree 那样显示依赖树
  5. 控制台下输出颜色更丰富

阅读全文 >>

Python 包管理及虚拟环境的应用(二: virtualenv)

原本想在一篇之内覆盖到 Python 的包管理以及各类虚拟环境的应用,没想根本就是一发不可收拾,恐怕两篇都完不了,所以也要进行重构。这里只涉及到 Python 的虚拟环境 venv 和 virtualenv,至于标题的话,也不想再改了,只作一,二,三编号,必要时仍能连缀成长篇。最后一篇将单独学习 pipenv 的应用。

以下序号也是承接上一篇 Python 包管理及虚拟环境的应用(一)

2. Python 虚拟环境

关于创建 Python 项目的虚拟环境,有三个工具可用, venv, virtualenv, 以及后面单独要学到的 pipenv

  1. venv , 即 python3 -m venv 命令,Python 3.3 及新版本自带了,为 Python 3.4 及以后的版本创建的虚拟环境会有 pip 和 setuptools 命令
  2. virtualenv 需要单独安装,但是它支持 Python 2.7 和  Python 3.3+, 创建的虚拟环境中带有 pip, setuptools 和 wheel 命令
  3. 另外,pyvenv 脚本也可用来创建 Python 虚拟环境,不过它自 Python 3.6 不推荐使用,建议用 python3 -m venv 命令

阅读全文 >>

Python 包管理及虚拟环境的应用(一: pip)

话说 Python 的哲学之一就是: 用一种方法,最好是只有一种方法来做一件事。可以用 python -m this 或在  python 交互界面下 import this 看到 The Zen of Python 有一句:

There should be one-- and preferably only one --obvious way to do it.

然而 Python 在关于包管理(依赖管理)一事上却让人面临了众多的选择。

即使是 Java 日趋发展庞大的今天,包管理工具也没有如今的 Python 复杂,Java 的包管理工具经历了手工下载 jar 包,Maven, Ant+Ivy, Gradle, sbt, 但主流的也就 Maven 和 Gradle, 并且它们兼具项目构建的功能。

这里有一个 Python 包管理工具变迁的视频: Kenneth Reitz - Pipenv: The Future of Python Dependency Management - PyCon 2018。再更早的 Python 依赖管理的方式不说,视频中提到了 阅读全文 >>

让 Python 的数据库查询返回字典记录

在使用  Python 进行数据库查询,通常情况下 cursor 的 fetchall, fetchmany 返回的是元组(Tuple) 的列表,所以对查询到的结果只能用索引下标来访问,而无法通过字段名来获取值。对 Java JDBC 的 ResultSet 操作,我们有两种获取值的方式,resultSet.getString(1) 和 resultSet.getString('name')。

其实只要能用数字索引访问到字段值也就足够了,查询后字段名可以由 cursor.description 获得。通过字段名来访问值唯一的好处估计是出错的概率小些罢了,比如 result['firstname'], result['lastname'] 总是比 result[1], result[2] 更不容易搞混,错误定位也会更轻松。

假如有下面的数据库表与两条记录 阅读全文 >>

Python 版的 try-with-resources -- with 上下文管理器

作为一个  Java 为母语的程序员来讲,学习起其他新的语言就难免任何事都与 Java 进行横向对比。Java 7 引入了能省去许多重复代码的 try-with-resources 特性,不用每回 try/finally 来释放资源(不便之处有局部变量必须声明在  try 之前,finally 里还要嵌套 try/catch 来处理异常)。比如下面的  Java 代码

try(InputStream inputStream = new FileInputStream("abc.txt")) {
    System.out.println(inputStream.read());
} catch (Exception ex) {
}

它相应的不使用 try-with-resources 语法的代码就是 阅读全文 >>

Spring Boot 与 Logback 日志配置

本文记录 SpringBoot 与 Logback 是如何工作的,即观察 SpringBoot 中 Logback  是怎么一步一步初始化的。用以测试的 SpringBoot 版本是 1.5.16, 而非最新的 SpringBoot 2。关于 SpringBoot 日志的官方文档在 Logging, 但不太详细或透彻。本文也不承诺说就理解得更有深度,只是为官方文档提供更多方面的参考。

SpringBoot 默认使用 Slf4J + Logback 来记录日志,对于一个基本的依赖于

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
</dependency>

的 Spring Boot 项目,上面组件依赖了 spring-boot-starter-logging 组件,而该组件又引入了以下几个依赖

  1. logback-classic:   依赖了 Slf4J
  2. jcl-over-slf4j
  3. jul-to-slf4j
  4. log4j-over-slf4j

相当于把其他的日志框架全桥接到了 Slf4J + Logback 上去了。 阅读全文 >>

WordPress 在 Linux 下不能向 Gmail 邮箱发邮件的问题

一年前解决了 WordPress 在 Linux 下不能发送邮件的问题,后来有段时间很正常,我的网站接收邮件的邮箱是 Gmail 的。但是近来,网站上有留言时极少收到通知邮件,怀疑是 Debian 下的  exim4 又不能正常工作了。但是试了如下的 PHP 脚本

$ php -a
Interactive mode enabled
php> mail('<my_gmail_account>@gmail.com', 'test subject', 'test content');
php > exit

从命令行上并没有提示任何的错误,但是检查我的 Gmail 信箱,死活就是收不到邮件。即使直接用  mail 命令

echo Hello World | mail -v -s Test <my_gmail_account>@gmail.com

也是不行的。

查看日志文件 /var/log/exim4/mainlog, 发现有下面的错误信息 阅读全文 >>

Linux 下配置滚动日志之 rotatelogs

上一篇 Linux 下配置滚动日志之 logrotate, 介绍了定时服务 logrotate 的方式对日志进行滚动,删除旧归档。logrotate 是目前流行 Linux 发行版内置的定时服务,默认每日根据配置文件来滚动日志文件。那么它可能有一个弊端就是,如果每日增长的日志超大,同时会暴盘,那么就必须调整 logrotate 这个 cron 定时服务为每小时,或自定义的 cron 表达式来控制。

而本文所介绍的 rotatelogs 工具(与 logrotate 名称太过相似) 是采用管道操作的方式来控制日志的滚动,可以基于实时监控的日志文件大小来滚动日志,也可以配置像 logrotate 来定时滚动日志。rotatelogs 是出自于 Apache HTTP Server 家族的,它被用于 Apache HTTP Server 的就错误日志,访问日志的滚动控制。

类似于 rotatelogs 的工具不有一个老旧的 cronolog,也是应用管道操作控制日志,它早已无人问津,最近更新在五年前,且功能很弱,只带滚动,不能清理旧归档,磁盘空间占用仍然是无上限。 阅读全文 >>