Category: Frameworks

sbt 中单元测试并发执行

2016-04-13 | 阅读(974)

此次研究的目的原本是要使得 Play Framwork 2 中单元测试能够并发执行, 包括 JUnit 和 Spec 的测试用例, Play 2 的 activator 就是一个 sbt 的包装. 开发中发现我们 Play 2 中的单元测试是按序执行的, 实际上 sbt 下测试用例默认是并发执行的. 之所以 Play 2 的单元测试是按序的, 是因为 activator 设置了把 sbt 的两个属性 fork in Test := true 和 parallelExecution in Test := false, 见 PlaySettings.scala, 它们默认分别为 false 和 true. 这使得默认设置下 Play 2 中的所有测试无法并发执行.

sbt 默认的 fork 是 false, Play 2 改为 true 之后便可以使用 javaOptions in Test := "-Dkey1=value1" (注: 如果 fork 为 false 的话, javaOptions 将无效.) 往单元测试中参数了, 这也是为什么在 Play 2 的单元测试中无法获得启动 sbt 时(像 sbt -Dkey1=value) 的参数, 不同一个 JVM 啊.

那是不把 Play 2 的 fork in Test 和 parallelExecution in Test 分别改回成 false 和 true 就可以让测试用例并发执行了呢? 答案是 Yes. 但我们得相信 Play 2 把它们预设为 true 和 false 是有它的用意的, 比如集成测试的每个用例都会开启本地的 3333 端口, 如果让两个集成测试同时执行将会造成端口冲突. 细致说来, Play 2 其实是懒政, 只管一刀切而让所有测试按序执行而影响了效率, 如能利用好 sbt 的测试分组机制是可以达到测试的并发执行的.

这里引出 sbt 执行测试的几个机制:

1) sbt 总是对测试进行分组, 默认时所有的测试都包含在 <default> 组中, 可用 show testGrouping 查看, 如

阅读全文 >>

拆分 Playframework 2 的 routes 为多个文件

2016-02-22 | 阅读(869)

我们用 Playframework 2 时，当 routes 中太多的路由配置时，我们可能会考虑把它们归类分布到多个文件中去。比如按 API 或用途分，有些是 RESTful API，有些是 Web 页面的，对于这种情景，我们可以由以下几个文件来组织：

1. routes 文件，这个仍然是充当入口

这里穿插着来解释下，-> 是固定写法，表示要去别外寻找了，紧接着的 /, /api, 和 /web 是分类路由的上下文了，例如，访问 api.routes 中定义的 /customers 的完整 API 路径就是 /test/customers。最后一部分是全类名，并非指别的路由文件的名称，像文件 general.routes 编译后会生成 general 包下生成  Routes.scala 文件，即类为 general.Routes. 阅读全文 >>

Play2.3 自定义模板类型 -- Java 版

2014-09-07 | 阅读(962)

在上一篇 Play2 自定义模板类型 (Java&Scala)，是基于 Play2.2 怎么自定义 Json 模板类型，分别用 Java 和 Scala 实现。从 Play2.3 开始，模板明确了是用 Twirl，所以构建文件上的配置略有不同，并且模板编译出的源文件位置也不一样，Play2.2 前生成的模板源文件在 target/scala-2.10/src_managed/main/views 目录，现在是生成在 target/twirl/main/views 目录。

在 Play2.3 中仍然是默认只支持 html, txt, xml, js 四种类型的模板，见 SbtTwirl。我们这里还是以增加 Json 模板支持为例，且只介绍用 Java 的方式。因为 Play2 尽管可以用 Java 来编写应用，但实现部份基本是 Scala，所以如果用 Scala 来进行扩展相对来说来比用 Java 简单些。

Play2.3 官方的自定义模板的文档 Adding support for a custom format to the template engine 有些出入，似乎还未来得急更新，以实操为证。

还是从构建文件开始 阅读全文 >>

Play2 自定义模板类型 (Java&Scala)

2014-09-03 | 阅读(823)

Play2 默认支持的模板类型是 html, txt, xml 和 js，不在这些支持之列的模板文件即使放到 app/views 目录中，也不会被编译的。如果要支持自定义的模板类型就要些定制了，这比 Play1 复杂些。模板的定制包括在 Build.scala 或 build.sbt 中加上 templatesTypes 配置，并需创建 BufferedContent 和 Format 实现类。下面以增加 json 模板类型为例，兼顾 Scala 和 Java 的实现类，是基于 Play2.2 的，在 Play2.3 中又略有不同。

官方有相关的文档，参考：Custom formats on Scala, Custom formats on Java 和 模板定义参考.

在较新一些的 2.2 的 PlaySettings 中，可以看到

弄清了上面的原理后，开始我们的步骤

第一步：修改项目构建文件

在构建文件 build.sbt 或 Build.scala 中增加下面的内容作为项目的 setting 阅读全文 >>

为 Jackson 自定义序列化对象的 JSON 格式

2014-06-12 | 阅读(4,690)

伴随着 Play1, 我们原来使用的 JSON 库是 Gson. 回忆下 Gson 是怎么自定义序列化对象的 JSON 格式，大概是这样子的

GsonBuilder()..registerTypeHierarchyAdapter(Cat.class, new Cat());

然后 Cat 需要实现 JsonSerializer 的 serialize() 方法。

来到了 Play2 中，JSON 库变成了 Jackson，那么 Jackson 该如何为对象自定义 JSON 格式呢？

例如，默认时 Jackson 对 Map 类型输出的是一个 JSON 对象

Map("key1"->"value1", "key2"->"value2")     转换成 JSON 是 {"key1":"value1", "key2":"value2"}

当为适应某些客户端，对于 LinkedHashMap 类型，我们想要输出的是一个有序的 JSON 数组： [{"key1":"value1"},{"key2":"value2"}]

我们就应该自定义某些 Map 的序列化格式，实现方法有两种，addSerializer 和 @JsonSerialize，不管哪种方式都需事先具体化 JsonSerializer 类，并实现它的 serialize 抽象方法

所以我先来实现一个能序列化 Map 的 JsonArrayMapSerializer 类 阅读全文 >>

Play2 中使用自定义的路由器文件 routes

2014-05-08 | 阅读(1,083)

用过 PlayFramework 的都知道默认的路由器文件是 conf/routes，Play2 可以定义自己的 routes 文件。在默认的 application.conf 中有这么一段注释

# Router
# ~~~~~
# Define the Router object to use for this application.
# This router will be looked up first when the application is starting up,
# so make sure this is the entry point.
# Furthermore, it's assumed your route file is named properly.
# So for an application router like conf/my.application.Router,
# you may need to define a router file my.application.routes.
# Default to Routes in the root package (and conf/routes)
# application.router=my.application.Routes

也就是通过 application.router 可以定义自己的 routes 文件。上面的解释很容易把人搞混，问题在于何处是文件路径，何处是类路径，至少写着的 'conf/my.applicaton.Router 就是在混淆视听。对于上面的解释要明白下面几点 阅读全文 >>

Play1 直接调用 Action 方法，不作 302 跳转

2014-05-02 | 阅读(955)

用过 PlayFramework 的同学们应该都知道，Action 方法间的调用是进行的  302 重定向操作。

简单例子说明一下，当基于下面的 r1, r2 路由配置时，如果 Application.f1() 方法中调用了 f2() 方法，实际运作是 f1() 在调用 f2() 时，会先反向出 f2() 方法对应的路由  GET /r2，然后向 /r2 发出的一个 302 跳转.

上面也算是绕个弯形成了对 f2() 方法的调用，这也是非常合理，在 Action 中很容易理解的。

GET     /r1                                                                     Application.f1
GET     /r2                                                                    Application.f2
GET     /r3                                                                    Application.f3

为什么说会反向出 f2() 方法对应的路由，可以反证一下。

例如说在 f1() 中调用了一个 public static void f4() 方法，但是 f4() 并未出现在 routes 配置中，也就是 f4() 没有对应的路由配置，我们将会看到这样一个异常 阅读全文 >>

PlayFramework 1 自定义标签 -- FastTags

2014-04-14 | 阅读(1,263)

最早是用 HTML 来自定义标签，现在觉得 HTML 写有关逻辑的代码就有点不伦不类了，HTML 里着重是显示代码。前有一篇 PlayFramework 1 模板应用 -- Java 对象扩展 学习了对 Java 对象扩展的方式，如果不是基于已有对象类型进行方法扩展来进行调用，就可以自定义 FastTags 的方式。

Java 对象扩展的使用是 ${obj.abc()}, FastTags 标签是 #{abc}...${/abc}。

FastTags 标签类继承自 play.templates.FastTags，标签对应方法的原型是

public static void _tagName(Map<?, ?> args, Closure body, PrintWriter out,     ExecutableTemplate template, int fromLine)

这些都是得益约定优于配置，下面来几个例子，分别说明默认参数，命名参数，及多参数，标签体的处理。 阅读全文 >>

PlayFramework 1 模板应用 -- Java 对象扩展

2014-04-14 | 阅读(433)

涉及到页面显示的问题，用自定义标签总能够能事不少，即使是最原始的自定义 JSP 标签也有人乐此不疲，进化到  Play 中的自定义标签数得上很轻量级的实现，简单的只需要一小页文档 The template engine 就足矣。

概括起来 Play1 支持三种方式自定义标签: HTML 文件方式, 自定义 FastTags, Java 对象扩展方法. 前二者为面向过程的方式，第三种方式为面向对象的方式，是在往某种数据类型追加一个方法。

确切的说针对 Java 对象的方法的扩展并不能称之为自定义标签。

一个这样的场景，股票价格变化值要显示在页面上，根据正，负，零，再加上不同的区域四种条件分别显示为不同的颜色，比如美国分别为绿色，红色和黑色(注: 美国股市显示的颜色正好与中国相反)。假设 priceChange 是 Integer 类型，我们就可以定义对 Integer 对象的扩展，所在类必须继承自 JavaExtensions 类： 阅读全文 >>

PlayFramework 1 输出所有 WS.url() 访问的 URL

2014-03-29 | 阅读(2,730)

记录下这个其实没有多大的意义，新入手 Play 框架的应该直接就是用版本 2 了，只因我们还要系统工作在 Play1 下，所以记下来，估计在 Play2 中已无借鉴作用了。

我们在 Play1 中访问外部 WebService 资源都是用 WS.url(url)，然后调用它的 get(), post(), delete() 等相对应的 HTTP 请求方法。我们可以系统中所有通过 WS.url() 访问的 URL, 需找到切面，Play 是在哪里为访问的 URL 创建请求的。

看 WS 类的实现，它是一个 PlayPlugin 插件，其中定义了

private static WSImpl wsImpl = null;

来看 Play 是如何获得 WSImple 实现的，WS 插件的初始化方法中： 阅读全文 >>