2014年のplayframeworkと自分のpull request


これは Play framework advent calendar 2014 の10日目です。
9日目は play アプリケーションのクラスパス指定を短くする でした。


去年に引き続き、

今までPlay2にしたpull request
いくつかpull reqしたので、それを書き出してみます。


use Vector instead of List for improve performance.

pull reqをしたの自体は去年だけど、mergeされたのは2014になってからだし、去年のアドベントカレンダーのタイミング的に書いてなかったので、書きます。
Listの末尾にappendしていて、明らかに遅そうだったので、Vectorに変えてみただけです。パフォーマンス計測してないので、効果があったのか謎です。まぁ遅くなることはないだろう、くらいな・・・



fix OWrites implicitNotFound message

typoを修正しただけです。1文字のみ・・・



specs2 dependencies should be "test" scope

テストでしか必要ないはずのspecs2が、なぜか普通のスコープになっていたのを修正



update specs2 2.3.12

specs2のversion上げただけ。



update typesafe config 1.2.1

これもversion上げただけ



fix deprecation warnings in build files

ビルドファイルで、古いsbtのAPI使われたままで警告でていたので、それの修正



refactoring build files

project/plugins.sbtとproject/Dependencies.scalaで、両方にsbt-native-packagerやsbt-twirlの依存が書かれていたわけだが、version上げる際に2箇所修正するの面倒だし、片方だけ修正するミスが起こりえるよね?
というわけで、sbtが再帰的なことを利用
http://stackoverflow.com/questions/23944108/how-to-share-version-values-between-project-plugins-sbt-and-project-build-scala/24103453#24103453
して、1箇所にversion書けばいいようにした。という細かい改善



fix broken link

ドキュメント内のsbtのページのURLが404になっていたので修正



update specs2

再びspecs2のアップデート。2014年にはscalaz7.1.0がでたことにより、specs2が7.1系に依存したわけだが、playが依存してるspecs2が古いままだと、playのテストで新しいscalazが使えないままになるので、上げたかった、という。

しかし、これにより、以下の問題

specs2 で unresolved dependency: org.scalaz.stream#scalaz-stream_2.11;0.5a: not found

を発生させちゃったので、別途違うpull reqした(後述)。

この問題が発生するの知ってたけど
「あえて、scalaz-streamがデフォルトでスコープに入るの面白いかな?」
と思ったけど、よく考えたら、scalaz-streamの新しいversion使いたいのに、逆に古いversionが邪魔になる、というのが将来的にありえるので、そんな不純な動機でscalaz-streamが入ってるのはよくないですね



backport #1938 for 2.2.x

RRC的におかしい、禁止されてる?文字をURLに入れると、playが変な箇所で例外出して500になるというもの。
他の人がplay2.3系で修正済みのものだったが、2.2系にbackportして欲しかったので、cherry-pickしてpull reqだけした。

2.2系では、2.2.6以降にこの修正入ってます。



add CanBuild22#apply, join, reduce, tupled

特に理由もなく、なぜか1つ足りなかったのですが、なぜ今までだれも加えなかったのか・・・。
まぁいずれにせよ、22超えたらだめなので、そんなときのためにライブラリ作ってるので、よかったらどうぞ

252要素のcase classまでのplayframeworkのJsonのReadsやWritesやFormatを生成できるライブラリ作った
playframeworkのJsonのReadsやWritesやFormatで要素数が23以上の場合のcase class用のコード生成sbt pluginをつくった
https://github.com/xuwei-k/play-twenty-three
http://scalajb.appspot.com/23?numbers=25



add Json#parse(input: InputStream)

InputStreamを直接引数にとるJsonのparseがあってよいのでは?ということに気がついたので追加。Jackson自体が内部的にそういう仕組みがあるので、中間のStringが生成されない(?)などで、パフォーマンス的に有利なはず?



handle invalid header value

nettyさんが、httpのheaderのvalueに不正な文字( \f とか \u000b とか )を含んでると、IllegalArgumentExceptionを投げてくる、という酷い状態になっていたのを、残念な感じで修正。
強制的に400返すようにした。
(onBadRequestに渡して、ユーザーにハンドルさせることすら簡単には不可能そうだったので諦めた、という意味)

エラーの文字列で判断という、だいぶ残念な修正方法なのに、よくmergeされたなーとも思うが、もっといい方法ないのか・・・。



fix specs2-matcher-extra dependency

後述、といいましたが、specs2の一部のモジュールがscalaz-streamに依存してしまってるのですが、その一部のモジュールはplay自体のテストにしか使っておらず、ユーザーが使うplay-testのモジュールには必要ないもの(具体的にはmatcher-extraのこと)だったので、依存を少なくしました。


ところで、specs2の作者が
「scalaz-streamをsonatypeにpublishして欲しい」
的なことをメーリングリストに投げてましたが、果たしてどうなることやら

https://groups.google.com/d/topic/scalaz/ZgmeVze3M6o/discussion