7つのクラスローダー 7つの世界
Playを触っていると謎のClassNotFoundExceptionが発生することがあります。 もしかしてそれはDEVモードだけで起きてはいないでしょうか？
先日、開発中のPlayアプリケーションで、ある依存ライブラリからClassNotFoundExceptionが発生するという現象にあたりました。 そのClassNotFoundExceptionはObjectInputStream.readObjectを呼び出した時に起きるのですが、なぜこのようなことが起きるのでしょう。
それではここでPlayのソースコードにある深イイコメントを見てみましょう。
/* * We need to do a bit of classloader magic to run the Play application. * * There are seven classloaders: * * 1. buildLoader, the classloader of sbt and the Play sbt plugin. * 2. commonLoader, a classloader that persists across calls to run. * This classloader is stored inside the * PlayInternalKeys.playCommonClassloader task. This classloader will * load the classes for the H2 database if it finds them in the user's * classpath. This allows H2's in-memory database state to survive across * calls to run. * 3. delegatingLoader, a special classloader that overrides class loading * to delegate shared classes for build link to the buildLoader, and accesses * the reloader.currentApplicationClassLoader for resource loading to * make user resources available to dependency classes. * Has the commonLoader as its parent. * 4. applicationLoader, contains the application dependencies. Has the * delegatingLoader as its parent. Classes from the commonLoader and * the delegatingLoader are checked for loading first. * 5. docsLoader, the classloader for the special play-docs application * that is used to serve documentation when running in development mode. * Has the applicationLoader as its parent for Play dependencies and * delegation to the shared sbt doc link classes. * 6. playAssetsClassLoader, serves assets from all projects, prefixed as * configured. It does no caching, and doesn't need to be reloaded each * time the assets are rebuilt. * 7. reloader.currentApplicationClassLoader, contains the user classes * and resources. Has applicationLoader as its parent, where the * application dependencies are found, and which will delegate through * to the buildLoader via the delegatingLoader for the shared link. * Resources are actually loaded by the delegatingLoader, where they * are available to both the reloader and the applicationLoader. * This classloader is recreated on reload. See PlayReloader. * * Someone working on this code in the future might want to tidy things up * by splitting some of the custom logic out of the URLClassLoaders and into * their own simpler ClassLoader implementations. The curious cycle between * applicationLoader and reloader.currentApplicationClassLoader could also * use some attention. */
Playはいわゆるソースコードのホットリロード機能などを実現するために、DEVモードではなんと7つのクラスローダーが駆使されているんですね。わー、すごい。
さて、この中で重要なのは 4.applicationLoader と 7.reloader.currentApplicationClassLoader です。 applicationLoaderはライブラリをロードされているクラスローダー、一方reloader.currentApplicationClassLoaderはapplicationLoaderを親とするクラスローダーで、アプリケーションコードを読み込んでいます。
と、いうことは、Playアプリケーションのコードってreloader.currentApplicationClassLoaderにしか見えていないことになります。依存ライブラリ内のObjectInputStream.readObjectはapplicationLoaderを使っているからまあそりゃClassNotFoundExceptionが起きますね。
解決方法は、依存ライブラリがreloader.currentApplicationClassLoaderを使うようにすることです。依存ライブラリに修正入れなきゃいけないのがイケてないですがまあ仕方ない。この場合はただのObjectInputStreamの替わりに
class ObjectInputStreamWithCustomClassLoader( stream: InputStream, customClassloader: ClassLoader ) extends ObjectInputStream(stream) { override protected def resolveClass(cls: ObjectStreamClass) = { Class.forName(cls.getName, false, customClassloader) } }
のように利用するクラスローダーを選べるObjectInputStreamを作って、reloader.currentApplicationClassLoaderにあたるplay.api.Environment#classLoaderを利用します。これでClassNotFoundExceptionは出なくなります。めでたし、めでたし。
まとめ
- We need to do a bit of classloader magic to run the Play application.
- play.api.Environment#classLoader を使おう
PlayのWebCommandsの使い方
Playのドキュメントを見るときに、公式サイトに行かなくても手元で http://localhost:9000/@documentation というURLにアクセスすればドキュメントサイトが見えるということはご存知でしょうか？
これにはWebCommandsという仕組みで動いていて、ドキュメントのほかにもEvolutionsの実行ページの表示などにも使われています。 普通のアプリケーションを作る分には必要ないですが、開発用のライブラリにWeb UIをつけたいときなどは便利です。
例えば、/@hello, /@hello/:name というパスにアクセスすると反応するWebCommandは次のような具合です。
package controllers import javax.inject.{Provider, Singleton, Inject} import play.api._ import play.api.inject.{Binding, Module} import play.api.mvc._ import play.core.{HandleWebCommandSupport, WebCommands} // 処理本体 class HelloWebCommandHandler extends HandleWebCommandSupport { def handleWebCommand(request: play.api.mvc.RequestHeader, buildLink: play.core.BuildLink, path: java.io.File): Option[play.api.mvc.Result] = { val pathPattern = """/@hello/([a-zA-Z0-9_]+)""".r request.path match { case """/@hello""" => Some(Results.Ok("Hello!")) case pathPattern(name) => Some(Results.Ok("Hello, " + name + "!")) case _ => None } } } // 以下DIのためのお決まりのコード @Singleton class HelloWebCommand @Inject() (webCommand: WebCommands) { webCommand.addHandler(new HelloWebCommandHandler()) } class HelloWebCommandModule extends Module { override def bindings(environment: Environment, configuration: Configuration): Seq[Binding[_]] = { Seq(bind[HelloWebCommand].toSelf.eagerly) } }
DIのbindのためのコードが多くて目がやられますが、HelloWebCommandHandlerというのが処理本体です。 簡単ですね。パスにマッチしたらなにか結果をOptionにくるんで返せばいいわけです。 あとはモジュールをapplication.confで登録すれば動きます。
play.modules.enabled += "controllers.HelloWebCommandModule"
以上、scalamatsuri前の小ネタでした。
Playに依存しないコードを書く
フレームワークの便利さとコードの柔軟性とのバランスの話。
PlayにはいわゆるMVC的な機能の他にいろいろと便利っぽいモジュールが付いていますが、 実際そいつらを使っていると依存関係や柔軟性の面でちょくちょく困ることがあります。 最近何度か困ったのはプロジェクトを分割する場面です。
Playでプロジェクトをスタートするときはwebアプリケーションのプロジェクトとしてスタートするわけで、 シンプルに次のような構成をとります。
. ├── app ├── build.sbt ├── conf ├── public ├── test └── test
しかし、だんだんプロジェクトが進むにつれて、あ、webアプリだけじゃなくてバックエンドでバッチ動かす必要あるわ、となったりします。バッチからも今までに書いたコード使いたいな。じゃあ共通コードをcoreっていうサブプロジェクトに移そうか。coreはplayには依存させたくないなあ。
こんな構成にしたい。
.
├── batch
│ └── src
├── build.sbt
├── core
│ └── src
└── web
├── app
├── conf
├── public
└── test
でもこれが意外にめんどうだったりします。
今まで書いたコードがPlayに依存していると、そのコードはbatchでは使うことができません。 たとえばPlayにはwsというHTTPクライアントライブラリが付属していますが、wsはplay.api.Applicationに依存しています。つまりPlayアプリケーションが起動している状態でなければ使えません。 従って、batchでもHTTPクライアントを使いたい場合はwsではなく他のHTTPクライアントへの置き換え作業が発生します。最初っからws使わなければよかったね...
wsのほかにも
あたりは動作するためにplay.api.Applicationが必要なのでめんどうです。
(追記・捕捉） Play2.4からはDI前提のAPIにApplicationに依存しないものもあります。 ただしモジュールレベルでは依存関係があるので、結果的にはcoreをPlayに依存させることになります。 互換性のために以前のAPIを残しているからと思われるので今後改善される可能性はありそうです。
あと、configなども
// play.api.Play.currentはplay.api.Applicationのインスタンス play.api.Play.current.configuration.get.....
というようにplay.api.Applicationをいじるコードを書いてしまいがちなので注意が必要です。 （それ以前にテストしにくいからやめたほうが良いですね）
設定ファイルを読み込むところは局所化して、必要な設定はコンストラクタ経由で渡すとかそういう手間のかけ方をするのが良いでしょう。
まとめ
Play2.4のプラグインシステムにある欠陥について
私の理解が正しければ、Play2.4のプラグインシステムにはプラグインの起動順が制御できないという大きな欠陥があります。Play2.3以前はplay.pluginsファイルに優先度を記述するというイケてない感が漂うやり方ではありましたが、問題なく制御することができていました。
Play2.4からはプラグインをDIコンポーネントとして記述するようになりました。play.pluginsファイルはなくなり、優先度ではなくコード中に記述してあるコンポーネント間の依存関係を利用して起動順が結果的にうまくいくようになっています。
ただし全てのプラグインがコードを介して依存しているわけではありません。例えばflyway-playのようなデータベースマイグレーションを行うライブラリはscalikejdbc-fixtureのようにデータベースフィクスチャプラグインよりも先に起動する必要がありますが、コード上で依存させるわけにはいきません。flyway-playではなくplay-evolutionsを使うときや、マイグレーションツールを全く使わないという選択ができなくなるためです。
Playの開発チームとしてはプラグイン間にコードにはない単純な起動順という関係があるのは間違いであるという態度を取っています。 つまりflyway-playとscalikejdbc-fixtureの実装に責任があるとの指摘を受けました。 ちょっと何を言ってるのかわかりませんが、少なくとも2.3のプラグインからの移行先としてはこのようなケースは当然考慮されるべきです。そもそも移行期間すら設けられずに行われた変更なのです。
まとめるとPlay2.4のプラグインシステムではPlay2.3で行っていたプラグインの起動順制御ができないため、プラグインの組み合わせによってはPlay2.3から2.4への移行はできません。Play2.4の重大な欠陥と言えますが、1日やりとりしてもPlay開発チームと話がかみ合っていないので、修正される見込みはないかと思います。
https://github.com/playframework/playframework/pull/4960
追記
そのあと、一応の対処法は教えてもらいましたので書いておきます。 教わった例はFixtureコンポーネントのラッパーを書いて、それをMigrationsComponentに依存させろ、というもの。
class DBFixturesComponentWrapper @Inject() (migrations: MigrationsComponent) { val dbFixturesComponent = ??? }
これはMigrationsComponentをコンストラクタで受け取ってるのでMigrationが先に起動するわけですが、FixturesComponentはDIではなく手動でインスタンス化しています。 次のようなコードにするほうが自然に見えるかもしれません。DIで起動順を制御しようとするのは結局失敗だったということです。
class DBFixturesComponentWrapper @Inject() { val migrationsComponent = ??? val dbFixturesComponent = ??? }
Slick のコードを生成する sbt プラグインを作りました
Slick コードを生成のイブラリがあり、公式のほうにいくつか使い方のサンプルがありますが、毎回コピペするのもなあと思って sbt プラグインにしました。今のところ Slick 2.1.0 に依存しています。Slick 3.0.0 が出たらそれ用のバージョンも出そうと思います。
インストールは plugins.sbt に addSbtPlugin を加えた上で、コード生成に使う JDBC ドライバを追加します。
// plugins.sbt addSbtPlugin("com.github.tototoshi" % "sbt-slick-codegen" % "0.1.0") // Database driver // For example, when you are using PostgreSQL libraryDependencies += "org.postgresql" % "postgresql" % "9.4-1201-jdbc41
build.sbt の設定は以下のような感じです。
// build.sbt import scala.slick.codegen.SourceCodeGenerator import scala.slick.{ model => m } // required slickCodegenSettings // required // Register codegen hook sourceGenerators in Compile <+= slickCodegen // required slickCodegenDatabaseUrl := "jdbc:postgresql://localhost/example" // required slickCodegenDatabaseUser := "dbuser" // required slickCodegenDatabasePassword := "dbpassword" // required (If not set, postgresql driver is choosen) slickCodegenDriver := scala.slick.driver.PostgresDriver // required (If not set, postgresql driver is choosen) slickCodegenJdbcDriver := "org.postgresql.Driver" // optional but maybe you want slickCodegenOutputPackage := "com.example.models" // optional, pass your own custom source code generator slickCodegenCodeGenerator := { (model: m.Model) => new SourceCodeGenerator(model) } // optional // For example, to exclude flyway's schema_version table from the target of codegen slickCodegenExcludedTables in Compile := Seq("schema_version")
sourceGenerators in Compile に加えることでコンパイルの前にコード生成が走ります。この設定では毎回コード生成が走りますが、毎回同じファイルが生成されるため、再コンパイルされることはありません。コード生成自体の時間が気になる場合は slickCodegen タスクにキャッシュを入れればよいと思います。sbt の FileFunction.cached とか使えば簡単に実装できると思います。
デフォルトでは Slick の SourceCodeGenerator によりソースコード生成が行われますが、以前このブログにも書きましたが、java.sql.Timestamp じゃなくて joda-time を使いたい、などということがあると思います。そのときは slickCodegenCodeGenerator にカスタマイズした SourceCodeGenerator を設定します。
slickCodegenCodeGenerator := { (model: m.Model) =>
new SourceCodeGenerator(model) {
override def code =
"import com.github.tototoshi.slick.PostgresJodaSupport._\n" + "import org.joda.time.DateTime\n" + super.code
override def Table = new Table(_) {
override def Column = new Column(_) {
override def rawType = model.tpe match {
case "java.sql.Timestamp" => "DateTime"
case _ =>
super.rawType
}
}
}
}
}
データベースマイグレーションと共存させる
本編ここから。Slick に限った話ではないですが、すでにデータベースにあるテーブルを使ってコード生成を行うという仕組みは、データベースマイグレーションツールとの相性が非常に悪いです。play-evolutions や play-flyway は Play アプリケーションの起動時にデータベースマイグレーションを行うため、コード生成とマイグレーションがデッドロックしてどうしようもありません。
今のところは dev-mode のデータベースマイグレーションは play-flyway ではなく、Flyway の sbt プラグインを使うことで回避しています。テストのときなどの Slick のコード生成が終わった後では play-flyway も使えるようになります。ちょっとダサい気がしているけれど、追加する設定も少ないし、まあ良いかという感じです。sbt ではなく Flyway のコマンドラインツールを使うというのでも良いと思います。
困ったことに Flyway の sbt プラグインを使ったからといってこの問題とさよならできるわけではありませんでした。実はこのプラグインもコンパイルの後にマイグレーションを走らせる作りになっているため、Flyway 用に別の空プロジェクトを使って、そこでマイグレーションを行う、というようにしました。flyway という空プロジェクトを作ったら、マイグレーションは flyway/flywayMigrate というコマンドで実行できます。
設定を見てもらうのが早いと思うので、サンプルプロジェクトにまとめて置きました。
回避に回避を重ねましたが、最終的な設定としては一応理解可能なレベルにまとめられたのではないかと思います。最初はサブプロジェクトで FakeApplication を使って無理やり Play.start してマイグレーションを走らせて...みたいなことをしていた（意味わかるでしょうか）のですがそれよりはずっと良いと思います。
Flyway プラグインを Play 2.4 対応しました
Play 2.1-2.3 向けにサードパーティプラグインとして play-flyway を開発してきましたが、少し前に Flyway の GitHub Organization に加えてもらい、めでたく公式モジュールとなりました。groupId も com.github.tototoshi から org.flywaydb になりました。
Play 2.4 はまだ final がリリースされてないのでまだスナップショット版ですが、 今の最新である Play 2.4-M2 向けにビルドしたものをリリースしておきました。
build.sbt に
resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots" libraryDependencies += "org.flywaydb" %% "flyway-play" % "2.0.0-SNAPSHOT"
と書いた上で、conf/play.plugins ではなく、conf/application.conf に
play.modules.enabled += "org.flywaydb.play.PlayModule"
と書くと有効になります。そのほかは今までの play-flyway と同様です。
