Play Framework 2.5のルーティングで詰まったので動作を調べた
サブプロジェクトを使ったときに上手くパスが設定されないようになってしまって解決まで時間が掛かったので、調べたことの記録。ちなみに調べた結果コンテキストパスでも上手く設定されないケースがありそうでした。
調査した環境
Play Framework 2.5.10
原因と対応
Play Frameworkを2.3から2.5にバージョンアップした際、アプリケーションの初期化中にメインモジュールからのパスではなくサブプロジェクトでのパスが直接指定されてしまう部分が出てきてしまいました。例えば、mainモジュールがsubモジュールに依存していたとして、subモジュールのindexメソッドへのリバースルーティングをmainモジュールで行った際、2.3なら「/sub/index」が取れていたのに「/index」が取れてしまうようになった、といった感じです。
コード例があった方がわかりやすいと思うので、サンプル作りました。GitHub - re-d-shark/routes-test
次のようなコントローラーを用意して、サブプロジェクトのパスを取ってみます。
callには、次のようなモジュールからDIされるCallクラスのインスタンスが入ります。
ここでは、GuiceのModuleでサブプロジェクトのコントローラーのメソッドのCallクラスを直にDIさせているだけですね。アプリケーションの初期化処理部分で色々やってた部分を簡略化しているので、あまり意味のない感じに見えるかもしれませんが…。
ルーティングはmain、subそれぞれ次のような感じ。
さて、subIndexを叩くと何が返ってくるでしょうか。同じメソッドを参照しているのだからDirectとInjectedで指す値は同じ値になって欲しいですね。答えは…
えぇ…。
調べたところ、2.4以降からPlay Frameworkが内部でGuiceを使うようになって動的にアプリケーションの設定をするようになったところが原因だったようです。Play Frameworkの初期化処理は2.3ではGlobalSettings.beforeStartで書いていたのですが、2.4以降ではGlobalSettingsは使われなくなりGuiceのModuleとしてDIする時に色々するようになりました。と認識しています。(GlobalSettings - 2.4.x)そのときにどのようにルーティングを決定しているのか見てみましょう。
Play Framework の起動とルーティング
Play Frameworkのアプリケーションがどのように立ち上がるのかを簡単に追いかけながらソースを見ていきました。ここからはそのときソースリーディングした流れを追跡していきます。だらだらソースを読むだけなので、後ろで要点をまとめてます。
エントリポイントは本番環境(ProdServerStartのmain)と開発環境(sbt runする)で違うようですが、最終的にplay.api.Applicationトレイトの実装クラスを作成し、それを元に動作するようです。デバッガで追っかけたりはして無いですが大体次のような箇所で指定しているようです。
本番環境:play.core.server.ProdServerStart。(余談ですがplay.core.server.NettyServer使うと今はdeprecatedって出るんですね…。変えなきゃ…。)
開発環境:play.sbt.PlaySettings。この辺りはよく理解していませんが、sbtでrunタスクを実行したらplay.sbt.run.PlayRunの中でなんやかんやしてplay.runsupport.Reloader経由でplay.core.server.DevServerStart#mainDevが実行されるようです。
ともかくどっちでも最終的にplay.api.Play.start(application)と指定しているわけです。ここで、applicationはApplicationクラスのインスタンスですが、GuiceApplicationLoaderによりBuiltinModuleで指定されたDefaultApplicationが生成されています。ややこしいことをしていればGuice以外のApplicationLoaderを使うこともできるようですが、ややこしいのでパスしました。
Play#startで何をやっているか見てみると…
def start(app: Application) { // First stop previous app if exists stop(_currentApp) _currentApp = app Threads.withContextClassLoader(app.classloader) { // Call before start now app.global.beforeStart(app) // Ensure routes are eagerly loaded, so that the reverse routers are // correctly initialised before plugins are started. app.routes // If the global plugin is loaded, then send it a start now. app.global.onStart(app) }
となっていますが、app.routesでroutesを呼び出してますね。Applicationクラスのroutesは…
@deprecated("Either use HttpRequestHandler, or have the router injected", "2.4.0") def routes: Router = { // Use a cached value because the injector might be slow if (cachedRoutes != null) cachedRoutes else { cachedRoutes = injector.instanceOf[Router] cachedRoutes } }
と定義されています。deprecatedが怖いですが、Play Frameworkが内部でGuiceを使うようになり、ルーティングはGuiceのinjectorからインスタンスを生成して取得しているようですね。ではこのRouterですが、先程のBuiltinModuleを見るとRoutesProviderから提供されているようです。
このRoutesProviderですが、次のように定義されています。
@Singleton class RoutesProvider @Inject() (injector: Injector, environment: Environment, configuration: Configuration, httpConfig: HttpConfiguration) extends Provider[Router] { lazy val get = { val prefix = httpConfig.context val router = Router.load(environment, configuration) .fold[Router](Router.empty)(injector.instanceOf(_)) router.withPrefix(prefix) } }
設定からコンテキストパスを取得して、Router.loadでRouterクラスのインスタンスを取得、コンテキストパスをwithPrefixに与えて返ってきたRouterクラスを返すという動作ですね。そして、そのRouter#loadは…
def load(env: Environment, configuration: Configuration): Option[Class[_ <: Router]] = { val className = PlayConfig(configuration).getDeprecated[Option[String]]("play.http.router", "application.router") try { Some(Reflect.getClass[Router](className.getOrElse("router.Routes"), env.classLoader)) } catch { case e: ClassNotFoundException => // Only throw an exception if a router was explicitly configured, but not found. // Otherwise, it just means this application has no router, and that's ok. className.map { routerName => throw configuration.reportError("application.router", "Router not found: " + routerName) } } }
と定義されています。ここでようやくEnvironmentとConfigurationからRouterクラスを生成しているのが分かりました。環境と設定クラスは追いかけませんが、routesファイル名の設定があればその名前から、なければ"router.Routes"をRouterクラスのインスタンスとしてリフレクションで生成しています。大分近づいてきた感じがありますね。
では、routesファイルからコンパイルされ作られたmainプロジェクトのrouter.Routesクラス定義を見てみます。
class Routes( override val errorHandler: play.api.http.HttpErrorHandler, // @LINE:1 MainController_0: javax.inject.Provider[main.controllers.MainController], // @LINE:3 sub_Routes_0: sub.Routes, val prefix: String ) extends GeneratedRouter { @javax.inject.Inject() def this(errorHandler: play.api.http.HttpErrorHandler, // @LINE:1 MainController_0: javax.inject.Provider[main.controllers.MainController], // @LINE:3 sub_Routes_0: sub.Routes ) = this(errorHandler, MainController_0, sub_Routes_0, "/")
コンストラクタにInjectアノテーションが付いており、エラーハンドラとmainプロジェクトのコントローラー、subプロジェクトのRoutesクラスがGuiceによってDIされ、prefixは"/"となるようですね。
そして、サブモジュールのRoutesクラスは…
class Routes( override val errorHandler: play.api.http.HttpErrorHandler, // @LINE:1 SubController_0: javax.inject.Provider[sub.controllers.SubController], val prefix: String ) extends GeneratedRouter { @javax.inject.Inject() def this(errorHandler: play.api.http.HttpErrorHandler, // @LINE:1 SubController_0: javax.inject.Provider[sub.controllers.SubController] ) = this(errorHandler, SubController_0, "/")
でした。mainプロジェクトと同じような定義ですね。今のところ、どちらもprefixが"/"となっていますが…。とりあえず続きを見てみます。RoutesProviderでrouter.withPrefix(prefix)としてmainのRouterクラスのwithPrefixが呼ばれています。これは
def withPrefix(prefix: String): Routes = { router.RoutesPrefix.setPrefix(prefix) new Routes(errorHandler, MainController_0, sub_Routes_0, prefix) }
と定義されており、router.RoutesPrefix.setPrefixでは…
package router { object RoutesPrefix { private var _prefix: String = "/" def setPrefix(p: String): Unit = { _prefix = p } def prefix: String = _prefix val byNamePrefix: Function0[String] = { () => prefix } } }
オブジェクトにmutableな変数"_prefix"を定義しており、設定値のprefixを代入していました!そして設定後にnew Routesでクラスを作り直しているのでprefixの値が置き換わったmainプロジェクトのRoutesクラスを返しましたね。
subプロジェクトのprefixはどうやって設定しているのかというと、mainのRoutesクラスのメンバ変数に、次の定義がありました。
// @LINE:3 private[this] val prefixed_sub_Routes_0_1 = Include(sub_Routes_0.withPrefix(this.prefix + (if (this.prefix.endsWith("/")) "" else "/") + "sub"))
ここでmainプロジェクトのRoutesクラスを作り直した際に、subプロジェクトのRoutes#withPrefixでmainプロジェクトのprefix+"sub"のprefixが設定されました。はぇ~…よくできてる…。さて、これでどのタイミングでサブプロジェクトのルーティングが決まるのか分かりましたね。アプリケーションの生成後に動的に決定していたと。つまるところ、これが設定されていないタイミングでRoutesクラスを呼んじゃダメということですね。…この動作だと、コンテキストパスを設定する場合にも影響が出ますね…。
では、問題になっていたModuleによる初期化処理はどのタイミングで実行されるか、言い換えると、GuiceApplicationLoaderがModuleをどのタイミングで読み込むかです。が、これはまあ、アプリケーションの作成前ですね。長くなったので細かく追いませんが、GuiceApplicationLoader#loadがApplicationインスタンスを作成するためにGuiceApplicationBuilderを作成し、GuiceApplicationBuilder#injectorでModuleを読み込んでいく、という動作です。
なので、初期化処理時にプレフィックスが設定されている必要があればRoutesをDIするようなクラスかプロバイダを作って、それ経由でバインディングすると良いですね。Moduleクラスを以下のように書き換えました。
package main import javax.inject.Inject import com.google.inject.{AbstractModule, Provides} import play.api.mvc.Call import play.api.routing.Router class Module extends AbstractModule { def configure() = {} @Provides @Inject def callProvider(routes: Router): Call = sub.controllers.routes.SubController.index }
では見てみましょう。
無事、プレフィックスが設定されたパスが取得できました。
まとめ
Play Framework 2.5.10では、Guice Moduleの読み込み→各種Play Frameworkの設定→アプリケーションの起動の順番で動作するようで、Moduleの読み込みの段階ではサブプロジェクトのRoutesクラスのパスやコンテキストパスが設定されない状態になってしまうようです。それらを使うような処理を書く際にはRouterクラスをDIしておきましょう。
感想
調べたときはGuiceを使いながら上手いことルーティングを動的に処理している!と感動しましたが、まとめている内にやっぱり紛らわしいなと思いました。最初に設定されていれば…。とはいえ、そうするとPlayの設定前に色々操作したい場合に不都合があるでしょうし、どこを直せば良いのかが分からなかったのとIssueにも上がってなさそうだったので、使い方が悪かったという感じがします。ソースを見れば回避方法は分かりましたし。しかし、ソースの中を追っかけていけるのは障害があったときになんとかなると安心しますし勉強になりますね。OSSのありがたみ…。
後、はてなブログに慣れていないせいでこの記事作成中に3回内容が吹っ飛びました。辛かった…。