play2系を触ってみて1系から劣化したなーと思うところがninjaではどうなってるか見てみました。
環境毎の設定切り替え
play2系ではprefixによる設定の切り替えは廃止され、環境別の設定ファイルを用意する仕様になりました。
個人的には、小規模で使う分には1ファイルに全環境の設定を書いておきたいので、若干劣化したなぁ、という感覚でした。
ninjaはほぼほぼplay1系と同じ仕様で、起動時に渡す変数をprefixとして設定を切り替える形です。こちらの方が使いやすいかなー。
http://www.ninjaframework.org/documentation/configuration_and_modes.html
- 起動時に ninja.mode を設定。
mvn ninja:run -Dninja.mode=dev
-
application.conf
database.name=database_production %dev.database.name=database_dev
自動実行ジョブ
play1系ではQuartzを使い、cronライクにシンプルに実装できましたが、
2系ではAkkaベースとなり設定の記述が複雑になってしまい、使いづらくなりました。
また、cronのように指定のタイミングで実行するのではなく、起動時から定期的に実行するだけの仕組みになりました。
ninjaではどうなったのか調べてみました。
http://www.ninjaframework.org/documentation/scheduler.html
- Jobクラス
@Singleton public class ScheduledAction { @Schedule(delay = 60, initialDelay = 5, timeUnit = TimeUnit.SECONDS) public void doStuffEach60Seconds() { // do stuff } }
-
Job登録
public class Module extends AbstractModule { protected void configure() { bind(ScheduledAction.class); } }
んー、記述は簡単ですが、できることはplay2系と同じですね・・・
cronのような仕組みはあまり好まれないんですかね?
Session
http://www.ninjaframework.org/documentation/basic_concepts/sessions.html
playのSessionはJava ServletのHttpSessionとは全く異なる仕組みで実装されており、
サーバーには何も持たず、Cookieにすべてのコンテキストを保存します。
これはplayの思想であるshared nothingを実現するため、サーバー間でコンテキストを共有しないようにするためです。
ninjaもこの思想は引き継がれているようで、ninjaのSessionオブジェクトに値を設定すると、ブラウザのCookieに保存する仕様になっていました。
小規模ならLBでスティッキーにしてサーバーに全部保存したいんですが、やはりninjaでもサーバ側で保持したいコンテキスト情報は、Memcached等を併用する必要がありそうです。