タグ

ブックマーク / kamekoopa.hateblo.jp (6)

  • Playframework2で自作プラグインを作る - 新しいフォルダ (3)

    Playframeworkのプラグイン*1とは? Playframeworkはプラグインにより機能拡張できるのですが、Playframeworkにおけるプラグインって何なん?というのは僕の中でも結構フワフワしています。 結局のところただのライブラリっぽいのですが、ライブラリではなくプラグインとして組み込むことの利点は、フレームワークの起動時、及び終了時に、フレームワークに任意の処理を実行してもらえるところですかね? 故に、何らかのデータストアへアクセスしたり、テンプレートエンジンを履き替えたりといった「何らかの初期化処理がないと使えないんだけど、アプリ内からそういうのに感心を持ちたくない」ようなモノがプラグイン化に値するのかなーと思ってます。 プラグインを作るには Playアプリに組み込む際にはjarになっててクラスパスに入ってれば何でもいい*2ので、mavenで作ろうが、sbtで作ろうが

    Playframework2で自作プラグインを作る - 新しいフォルダ (3)
    bluele
    bluele 2013/07/19
    enabledでプラグインの切り替え
  • Playframework2でjavaでフィルタを実装するメモ - 新しいフォルダ (3)

    備忘録です。Playのバージョンは2.1.1 GlobalSettingクラス(java用)にfilterを登録するらしきメソッドが生えていたので気になって調べていました。 filter作って登録できるなら色々出来る事もありそうだなーと思って調べてたんですが、ざっくりコード読んだ感じだと、自作のフィルタを作るための仕組みはScala用にはAPIがあるけれど、Java用には用意されていない様子で、Javaオンリーで自作フィルタを実装するには、ScalaAPIjavaから呼び出す必要がある模様。 で、実装したコードが以下。 結論から言うとかなりつらみがありました。 解説*1 *2 実装する必要があるメソッドは public EssentialAction apply(final EssentialAction next){} このメソッド。 多分引数として与えられるアクションはリクエストに

    Playframework2でjavaでフィルタを実装するメモ - 新しいフォルダ (3)
  • Playframework 2.0 (Java)で、JUnitのRunWithアノテーションが認識されなかった - 新しいフォルダ (3)

    備忘録。Playframeworkのバージョンは2.0.3、Javaです。 Playframeworkはフルスタックなフレームワークなので、テスト環境もあらかじめセットアップされています。 testディレクトリ配下に以下のようなJUnit4テストを置いておけば、コマンド一発でテストを走らせることができます。 public class HogeTest { @Test public void ほげほげテスト(){ //ほげほげ } } というわけで、以下の様なテストを書きました。 @RunWith(Enclosed.class) public class HogeTest { public static class 初期状態がほげの時 { @Test public void ほにゃらかテスト(){ //ほにゃほにゃ } } } …が、実行されません。 test-onlyコマンドでテストクラス

    Playframework 2.0 (Java)で、JUnitのRunWithアノテーションが認識されなかった - 新しいフォルダ (3)
    bluele
    bluele 2013/07/07
  • Playframewok 2.0 での環境ごとの設定の切替方法について考えてた - 新しいフォルダ (3)

    備忘録ですお。 継続的デリバリー曰く「あらゆる環境に同じバイナリをデプロイせよ」 開発環境とか番環境だとかで同じ設定を使っているなんてことは、まぁ、殆ど無いと思います。 DBの接続先とか、外部サービスのURIだったりとか。 なので、開発にデプロイする時と番にデプロイする時で設定情報を切り替える必要があるわけですが、よく取られるアプローチとしては任意の環境用にビルドするというのがあると思います。*1 つまり build develとか build prodみたいなことをして、それぞれの環境用の設定で、それぞれの環境用のバイナリを作るというアプローチです。 しかし、継続的デリバリーはこう言っています。 「いろんな環境に簡単にデプロイできるようになるし問題の切り分けしやすくなるから、どの環境にデプロイするかにかかわらず同じバイナリ使え。」 そうなると、アプリケーション体には設定へのポインタ

    Playframewok 2.0 での環境ごとの設定の切替方法について考えてた - 新しいフォルダ (3)
    bluele
    bluele 2013/07/05
  • 社内LTでPlayでJenkinsでBuildPipelineなデモが出来るまで。 - 新しいフォルダ (3)

    これです。 今回もほぼ個人用備忘録なので雑です。 デプロイメントパイプラインって何? from ke-m kamekoopa 入れたプラグイン Git Plugin Gitlab Hook Plugin 社内リポジトリがgit + GitLabなので Build Pipeline Plugin 肝 Copy Artifact Plugin 保存した成果物を取り回すため ジョブの作成 今回はデモ用なので簡単に、以下の3つのジョブ(フェーズ)を作りました。 commit-stage compile test stage*1 deploy(to 開発環境) commit-stageから自動発動 deploy(to ステージング環境) deploy(to 開発環境)から手動発動 まとめると commit-stage -[自動]-> deploy(to 開発環境) -[手動]-> deploy(to

    社内LTでPlayでJenkinsでBuildPipelineなデモが出来るまで。 - 新しいフォルダ (3)
  • Playframework2でCacheの実装をデフォルト(EhCache)から変更する方法のメモ。 - 新しいフォルダ (3)

    Playframework2ではplay.cache.Cache*1クラスを利用することで、keyとvalueで保存するキャッシュ機能を利用することができます。 しかしこのクラスはキャッシュ機能のフロントエンドを提供しているだけで、キャッシュのバックエンド(実際の実装)は、デフォルトではEhCacheと呼ばれるライブラリが利用されているようです。 で、Playframework2では、このキャッシュのバックエンドを任意の実装に切り替えることが出来るので、例えばファイルシステムを用いたキャッシュだとかmemcacheだとかにキャッシュ実装を変更したいと言った場合でも、アプリケーションコードの変更なしに切り替えることができます。 やり方 キャッシュのフロントエンドは、プラグインに登録されているクラスのうちplay.api.cache.CachePluginを継承したクラスを利用するように作られ

    Playframework2でCacheの実装をデフォルト(EhCache)から変更する方法のメモ。 - 新しいフォルダ (3)
    bluele
    bluele 2013/06/20
    session cache
  • 1