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等を併用する必要がありそうです。