1.  Rubyのインストール
2.  Bundlerのインストール
3.  Railsのインストール

1 Rubyのインストール

ruby編では、Cloud9というオンラインIDEサービスを使いましたが、今回はMacの環境でrubyのインストールからrails構築まで行います。rubyのインストールにはrbenvとruby-buildを使います。rbenvはrubyのバージョンを切り替えるために便利なツールです。複数のバージョンを管理してくれます。rubyのバージョンが違うプロジェクトを複数担当することもあるので、このツールで切り替えができると便利です。ruby-buildはrbenvのプラグインでrubyをインストールする際に使います。

rbenvをインストールする方法は２通ります。

最新バージョンを使いたいなら、githubからインストールします。
簡単にインストールしたいなら、homebrewからインストールします。githubにて２つのインストール方法が記載されています。以下の手順はhomebrewを使うインストールです。1.1 homebrewでのインストール
まずはそのhomebrewのインストールを行います。
前提として以下の２つが必要となります。
①Javaのインストール
②Xcode Command Line Toolsのインストール
上記が終わったら
homebrew公式
に書かれているように、（HPの記載が変更になっている場合もあるので注意）
コマンドプロンプトにて
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

をコマンドプロンプトにて実行します。
El Capitanの場合、/usr/localのパーミッション関係でエラーが起こることがるので、パーミッションの変更を行ってください。homebrewをインストールしたら、rbenvのインストールを行います。

$ brew install rbenv ruby-build

$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ source ~/.bash_profile

rbenvのバージョン確認をします。

rbenv -v

次にrbenvを使ってインストールできるrubyのバージョンを表示します。

rbenv install -l

上記のコマンドでバージョンが複数表示されるので、使いたいバージョンを指定して
rbenv install　コマンドを使い、rubyをインストールします。今回は2.2.2を指定しました。

rbenv install 2.2.2

以上でhomebrewでのrubyインストールは終了です。次の章のBundlerインストールを行ってください。

以下はgithubを用いたインストール

1.2 githubでのインストール
rbenvインストール。

$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
$ cd ~/.rbenv && src/configure && make -C src
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$~/.rbenv/bin/rbenv init

これでrbenvが使えます。

次はruby-buildをインストールします。

$ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build


rbenvのバージョン確認をします。

rbenv -v

次にrbenvを使ってインストールできるrubyのバージョンを表示します。

rbenv install -l

上記のコマンドでバージョンが複数表示されるので、使いたいバージョンを指定して
rbenv install　コマンドを使い、rubyをインストールします。今回は2.2.2を指定しました。

rbenv install 2.2.2

以上でgithubでのrubyインストールは終了です。次の章のBundlerインストールを行ってください。
2 Bundlerのインストール
rubyのインストールの次はBundlerのインストールです。BundlerとはGemのバージョンや依存関係を管理してくれます。。Gemとはrubyのライブラリのことです。インストールの手順は以下です。

$ rbenv exec gem install bundler

$ rbenv rehash

$ bundler -v

3 Railsのインストール

今回は新規アプリケーションを作成する場合を説明したいと思います。Bundlerを使ってRailsをインストールすると複数のプロジェクトに関わっている際にプロジェクト間のGemのバージョンの差異に悩まなくて良くなります。（下記のbundler insatallの項目を参照）
①新規アプリケーションを作成する場合
railsのプロジェクトフォルダを作成し、そこに移動し、

$ mkdir ProjectDir
$  cd ProjectDir

下記コマンドでGemfileを作成し、そのファイルにrailsをインストールするように書きます。GemfileとはBundlerで使うGemのバージョンが指定されており、このファイルに従ってGemfile.lockを作成します。Gemfile.lockにはGemfileで書かれているGemと、それと依存関係にあるGemの名前やバージョンが記載されています。

$ bundle init

Gemfileにインストール設定を記述します。ここではバージョン4.0.5を指定しています。

$ echo 'gem "rails", "4.0.5"' >> Gemfile

インストールコマンドを実行します。これによりvendor/bundle以下にRailsと関連するGemがインストールされます。このオプションを付けることでこのプロジェクト内だけにGemがインストールされます。

$ bundle install --path vendor/bundle

これでrailsコマンドでアプリケーションを作成できるようになりました。以下のコマンドで作成しましょう。

bundle exec rails new .

Gemfileの上書きの確認をされたら許可してください。

アプリケーションが作成できたら以下のコマンドでサーバーを立ち上げましょう。

bundle exec rails server

ブラウザでhttp://localhost:3000にアクセスして、Railsの初期画面が表示されているか確認しましょう。
これでRailsの導入は完了です。お疲れ様でした。

目次

Ruby開発環境構築
1. オンラインIDE（Cloud9）
2. ローカル環境にインストールしたい場合

Rubyを触ってみよう
1. 変数と条件分岐
2. 繰り返し
3. メソッド
4. クラス

開発環境構築

1.　オンラインIDEサービス（Cloud9）
Cloud9とはオンラインIDE（統合開発環境）サービスです。小規模なアプリケーションの開発やデータベースなどをクラウド環境で利用できるサービスです。
開発環境を整えるのは、プログラミングを学ぶ者にとって最初の難関となりますが、このサービスを使うと面倒な作業は必要ありません。すぐに始めたい人や、ローカル環境にインストールできなかった人はCloud9を使ってみましょう。
Cloud9

利用する手順は以下のとおりです。
１，Cloud9で新規ユーザー登録します。Sign_upをクリックし、必要な情報を記入してください。(GithubやBitBitbucketとも連携しており、そのアカウントからもログインできます。)

2,登録完了後、ダッシュボードが表示されるので、「Create a new workspace」をクリック。以下の様な画面が表示されます。

3,workspace名や公開設定を変更し、Blankテンプレートを選択。「create workspace」をクリック。
※RailsテンプレートやRails_Tutorialテンプレートは今回は使用しません。
※ターミナルで確認した所、BlankテンプレートはRailsは入っていませんが、Ruby(執筆時２．３)はインストールされています。
４，作成したworkspaceが表示されれば、完了です。

簡単ですね。これでクラウド環境でRubyが使えるようになりました。
左に表示されているファイルツリーで右クリックして、フォルダやファイルを作成します。拡張子は「.rb」を使います。

2．ローカル環境にインストールしたい場合
ローカルの環境にRubyをインストールする際には、公式サイトのドキュメントを利用すると良いでしょう。ここでは詳しいやり方は省略させていただきます。
公式サイト

Windows向け
公式サイトにあるようにWindowsにRubyをインストールする方法はいくつかあります。ソースからコンパイルしてインストール出来ない場合は、より簡単にインストールできるサードパーティ製のコンパイル済みのバイナリを使用すると良いでしょう。

Mac向け
MacではRubyは標準コマンドとして利用することができますが、使用したいバージョンよりも古い可能性があります。
自分で追加してインストールする場合、ソースからコンパイルしてインストールするか、パッケージ管理システムを利用してインストールするか選べます。

Rubyを触ってみよう

1. 変数と条件分岐
まずは変数の使い方と条件分岐です。

#変数の定義
#名前
name01="田中"
name02="高橋"

#点数
a=60
b=80

#点数の平均を求める式
ave=(a+b)/2

#条件分岐　if構文
=begin
if 条件 then
  条件が成り立った時に実行する処理
else
  条件が成り立たなかった時に実行する処理
end
=end
if a>b then
  max=a
  min=b
else
  max=b
  min=a
end

#コンソールに引数を出力する
print(name01,"さんの点数は",a,"点\n")
print(name02,"さんの点数は",b,"点\n")
print("二人の点数の平均は",ave,"点\n")
print("最高点は",max,"点\n")
print("最低点は",min,"点\n")

RubyではJavaと違い、変数の型定義を明示的に行いません。上記のようにそのまま変数に代入しています。
Rubyでは文末に；（セミコロン）は使いません。改行を文の区切りとして捉えます。そのため、インデント（字下げ）を行い、まとまりを強調し見やすくします。
条件分岐にif文を使います。thenを書き忘れないようにしてください。
printメソッドは引数をコンソールに出力するメソッドです。複数の引数を扱う場合は「,」で区切ります。

ファイルを作成したら、画面下部のターミナルで、実行してみましょう。
実行の仕方は「ruby ファイル名.rb」です。

aiueo111:~/workspace $ ruby sample01.rb
田中さんの点数は60点
高橋さんの点数は80点
二人の点数の平均は70点
最高点は80点
最低点は60点

2. 繰り返し

##繰り返し　for構文
=begin
for 変数 in オブジェクト do
  繰り返す処理
end
=end
sum=0
for i in 1..5
  sum=sum+i
end
print sum,"\n"

#繰り返し while構文：
=begin
while 繰り返し続ける条件 do
  繰り返す処理
end
=end
i=1
while i<4do
  print(i,"\n")
  i=i+1
end
#繰り返し timesメソッド
=begin
繰り返す回数.times do
  繰り返す処理
end
=end
2.times do
  print("２回繰り返します。\n")
end

aiueo111:~/workspace $ ruby sample02.rb
15
1
2
3
２回繰り返します。
２回繰り返します。

do~endをブロックと呼びます。ブロックの中に繰り返したい処理を書きます。
この他にも繰り返しメソッドがあるので、興味がある方は調べてみてください。

3. メソッド

=begin
メソッド構文:
def メソッド名(引数１，引数２，・・・・)
　　実行したい処理
end
=end

#メソッド定義
#コンソールに引数を出力するメソッド
def test(name="Ruby",point=0)
  print(name,"さんの点数は",point,"点\n") #()省略可
end

#メソッド呼び出し。
test()
test("田中",60)
test("高橋",80)

#平均点を求めるメソッド
def average(point01=10,point02=0)
  ave=(point01+point02)/2  
  return ave   #return文は省略可
end

#平均点のメソッド呼び出し
print("平均点は",average(60,80),"点\n")

#最高点を求めるメソッド
def max(a,b)
  #return文は省略している
  if a>b then
    max=a
  else
    max=b
  end
end
#最高点のメソッド呼び出し
print("最高点は",max(60,80),"点\n" )

name,point引数が空の状態でhelloメソッドが呼び出された時、メソッド定義部分で記載されている引数がデフォルトの値として代入されます。
メソッドの中でreturn文を用いて返り値を指定できますが、省略することも可能です。省略した場合は、メソッドの中で最後に得られる値が返り値となります。

aiueo111:~/workspace $ ruby sample03.rb
Rubyさんの点数は0点
田中さんの点数は60点
高橋さんの点数は80点
平均点は70点
最高点は80点

4. クラス

class EnglishTest
  #initializeメソッドは初期化のためのメソッド(Javaだとコンストラクタ)
  def initialize(name="Ruby",point=0)
    @name=name  #インスタンス変数に引数を代入
    @point=point
  end
  
  #ゲッター　参照のみ可能
  attr_reader :name,:point
  #セッター　変更のみ可能
  #attr_writer :name,:point
  #アクセスメソッド（参照、変更の両方を可能にする）
  #attr_accessor :name :point
  
  #インスタンスメソッド定義
  #コンソールに引数を出力するメソッド
  def test
   print(@name,"さんの点数は",@point,"点\n") #()省略可
  end
  
end
#オブジェクトの生成
ruby=EnglishTest.new
tanaka=EnglishTest.new("田中",60)
takahashi=EnglishTest.new("高橋",80)
#メソッド呼び出し
ruby.test
tanaka.test
takahashi.test
#ゲッターにより、nameやpointを参照できるようになる。
p tanaka.name
p takahashi.point

クラスを使うことによって初期化メソッドのinitializeメソッドとインスタンス変数が使えるようになりました。
initializeメソッドはオブジェクトが生成される際に呼ばれ、必要な初期化処理はここに記載します。ここでも引数がない状態でオブジェクト生成されるときは、デフォルトの値が呼ばれます。
@で始まる変数はインスタンス変数と呼ばれ、同じインスタンス内であれば、他のメソッドからもその値を参照や変更ができます。
ゲッターにより、他のインスタンスからnameとpointが呼び出せるようになりました。

aiueo111:~/workspace $ ruby sample04.rb
Rubyさんの点数は0点
田中さんの点数は60点
高橋さんの点数は80点
"田中"
80

最後に
だいぶ駆け足でRubyを紹介しましたが、いかがでしたでしょうか？わかりづらいところや、もう少し詳しく書いて欲しい所があれば、コメントなどでいただけるとありがたいです。

今後もRubyの続きや新しくRailsの技術ブログも書く予定なので、気になる方はチェックしてみてください。

目次

1. クラス（クラスメソッドとクラス変数）
2. 継承
3. モジュール
4. 例外処理

前回はクラスを作り、インスタンスメソッドを使うところまでを記載しました。今回はクラスメソッドの書き方から始めたいと思います。

1. クラスメソッドとクラス変数

class EnglishTest
#クラスメソッド
=begin
def クラス名(もしくはself).メソッド名
  実行したい処理
end
=end
  def EnglishTest.title(title)
    print title,"テストの点数を発表します。\n"
  end
end
#クラスメソッドの呼び出し
EnglishTest.title("英語")

クラスメソッドは、def クラス名(もしくはself).メソッド ~ endで表します。クラスメソッドを呼び出すには「クラス名.メソッド名」と書きます。

複数のクラスメソッドを纏める書き方もあります。

class EnglishTest
#発表した人数をカウント
  @@count=0

#初期化メソッド
  def initialize(name="Ruby",point=0)
    @name=name  
    @point=point
  end
#アクセスメソッド
  attr_reader :name,:point
  
#インスタンスメソッド
  def test
   @@count+=1
   print(@name,"さんの点数は",@point,"点\n") #()省略可
  end
 
#クラスメソッド
  class << EnglishTest
    def title(title)
      print title,"テストの点数を発表します。\n"
    end

    def count
      @@count
    end
  end
end

#クラスメソッドの呼び出し
EnglishTest.title("英語")

#オブジェクトの生成
ruby=EnglishTest.new
tanaka=EnglishTest.new("田中",60)
takahashi=EnglishTest.new("高橋",80)
#メソッド呼び出し
ruby.test
tanaka.test
takahashi.test
#クラス変数の呼び出し
puts EnglishTest.count,"人の点数を発表しました。\n"

クラスメソッドを複数書く場合はclass << EnglishTest ~ endの中に書きます。インスタンスメソッドと同じような書き方ができ、わかりやすくなります。

@@で始まる変数はクラス変数と呼ばれるものです。このクラスのすべてのインスタンスで共有できる変数です。クラス変数を参照するには自分でアクセスメソッドを用意しなければいけません。上記ではtestメソッドが呼び出される回数を記録しています。

以下は実行結果です。

英語テストの点数を発表します。
Rubyさんの点数は0点
田中さんの点数は60点
高橋さんの点数は80点
3
人の点数を発表しました。

２. 継承

class Human
  def initialize(name="you")
    @name=name
  end

  def morning
    print "おはよう\n"
  end

  def hello
    print "こんにちは, ", @name,"さん\n"
  end 
end

#継承の構文
#class クラス名 < スーパークラス ~ end
class John < Human
  def morning
    print "Goodmorning\n"
  end
  
　　def bye
　　　　　print "Goodbye\n"
 end
end

john=John.new("John")
john.morning
john.hello
john.bye

スーパクラスがHuman,サブクラスがJohnになります。スーパークラスのmorningメソッドをサブクラスのmorningメソッドでオーバーライド（上書き）し、サブクラスで新しいbyeメソッドを追加しています。スーパークラスのinitializeとhelloメソッドはサブクラスには記載されていませんが、継承されているので、呼び出すことができます。

Goodmorning
こんにちは, Johnさん
Goodbye

３. モジュール

モジュールはクラスと書き方が似ていますが、クラスと違いインスタンスを持つことができません。また継承もできません。処理だけを纏める機能を持ちます。以下のように記載します。

#モジュール作成
=begin
構文
module モジュール名
  モジュールの定義
end
=end

module AbcModule
 Number="1.0"  #定数

 def hello(name)
 print name,"さん、こんにちは\n"
 end 
#モジュール関数として登録
 module_function :hello
end

p AbcModule::Number
AbcModule.hello("John")

include AbcModule
p Number
hello("Sara")

モジュールは「モジュール名.メソッド名」という形で参照できます。これをモジュール関数といいます。注意しなければいけないのは、モジュール関数を定義しただけでは、モジュール名.メソッド名で呼び出せません。module_functionでモジュール関数を外部に公開して呼び出せるようになります。

モジュールをincludeすることによって、モジュール名を省略することができます。

"1.0"
Jognさん、こんにちは
"1.0"
Saraさん、こんにちは

モジュールをクラスにインクルードすることを「Mix-in」とよびます。モジュール内のメソッドなどをクラスに取り込むことができます。

module AbcModule
  #Class1とClass２で共通のメソッドをまとめる
end

class Class1
  include AbcModule
  #固有のメソッドを記載
end

class Class2
  include AbcModule
  #固有のメソッドを記載
end

４. 例外処理

プログラム実行で起きるエラーは以下のものがあります。

• データのエラー
• システムのエラー
• プログラムのエラー

例外処理はこのようなエラーが発生した際に、実行されます。今回はraiseメソッドを使って、自分で例外を発生させます。

class ErrorTest
=begin
  begin
    例外が発生するかもしれない処理
  rescue
    例外が発生した際の処理
  end
=end  
  def initialize(name)
    @name=name
  end
 
  def hello
    begin
      raise
      print @name,"\n"
    rescue
      print "エラーが発生しました。\n"
    end
  end  
end

john=ErrorTest.new("John")
john.hello

例外処理は、begin~rescue~endを使います。beginに例外が発生するかもしれない処理を書き、rescueに例外が発生した際の処理を書きます。

上記では例外が発生するかもしれない処理の中でまずraiseメソッドが呼ばれ、その後printメソッドが呼ばれています。しかしraiseメソッドは例外を起こすメソッドなので、このメソッドが呼ばれた時点でrescueに処理が移ります。処理が移ったので、rescue側のprintメソッドが呼ばれ、以下が実行結果として出力されます。

エラーが発生しました。

早足でRubyを紹介してきましたが、いかがでしたでしょうか？
Rubyが気になった方は是非、開発環境を整えて、コードを書いてみてください。
次回はRubyのフレームワークであるRailsの紹介をしたいと思います。

前回はCriteria APIの基本と利点をご紹介しました。今回はCriteria APIの実戦的な機能をいろいろとご紹介します。

準備・エンティティクラスとメタモデルクラスのサンプル

次のようなエンティティクラスとメタモデルクラスが存在することを前提に進めていきます。

まずはUserエンティティクラスです。

package sandbox.entity;

import javax.persistence.Column;
import javax.persistence.Embedded;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    Long      id;

    @Column(length = 150, unique = true, nullable = false)
    String    name;

    // getter/setterは省略
}

次にUserエンティティのプロパティの型を表すメタモデルクラスです。

package sandbox.entity;

import javax.annotation.Generated;
import javax.persistence.metamodel.SingularAttribute;
import javax.persistence.metamodel.StaticMetamodel;

@Generated(value="Dali", date="2016-02-12T22:59:19.623+0900")
@StaticMetamodel(User.class)
public class User_ {
	public static volatile SingularAttribute<User, String> name;
	public static volatile SingularAttribute<User, Long> id;
}

それではCriteria APIを見ていきましょう。

Where条件にメタモデルクラスを使う

メタモデルクラスは、Criteria APIによるクエリの型安全性を高めるという重要な役割を持っています。

冒頭で示したUserというエンティティクラスをnameプロパティの値で絞り込むクエリを作ってみましょう。

private static void selectUsersByName(final EntityManager em, final String pUserName) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<User> query = builder.createQuery(User.class);
    final Root<User> root = query.from(User.class);
    query.where( //
            // メタモデルクラスを使ってカラムを指定する
            builder.equal(root.get(User_.name), pUserName) //
    );
    final List<User> result = em.createQuery(query).getResultList();
    for (final User user : result) {
        System.out.println(user);
    }
}

eclipseの入力補完の様子を見ると、fromに指定したエンティティクラスに応じたメタモデルクラスが候補として表示されることが分かると思います。

Where句に複雑な条件を設定する

検索画面のようにWhere句が動的かつ複雑になる時に、Criteria APIは威力を発揮します。例えば入力のある条件はWhere句に加えるが、入力のない条件はWhere句に加えない、という処理をJPQLで書くのは割と大変です。

private static void selectUsersByName(final EntityManager em, final String name) {
    final StringBuilder s = new StringBuilder("select e from User e where 1 = 1");
    if (name != null) {
        s.append(" and e.name = :name");
    }

    final TypedQuery<User> query = em.createQuery(new String(s), User.class);

    if (name != null) { // 存在しないパラメータを設定すると例外が生じるため、再度チェックせざるを得ない！
        query.setParameter("name", name);
    }

    final List<User> result = query.getResultList();
    for (final User user : result) {
        System.out.println(user);
    }
}

これをCriteria APIで書き直すと、とても素直なプログラムになります。

private static void selectUsersByName(final EntityManager em, final String name) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<User> query = builder.createQuery(User.class);
    final Root<User> root = query.from(User.class);

    final List<Predicate> where = new ArrayList<>();
    if (name != null) {
        where.add(builder.equal(root.get(User_.name), name));
    }

    query.where(where.toArray(new Predicate[where.size()]));

    final List<User> result = em.createQuery(query).getResultList();
    for (final User user : result) {
        System.out.println(user);
    }
}

 関連クラスを同時に取得する

JPAの強みの１つにエンティティクラスの関連をコードで表現出来ることがあります。下記はUserを親に持つTagというエンティティを作っています。

package sandbox.entity;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;

@Entity
public class Tag {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    Long   id;

    @Column(length = 50, unique = false, nullable = false)
    String name;

    @ManyToOne(fetch = FetchType.LAZY)
    User   user;

    @Column(nullable = false)
    long   starCount;

    // getter/setterは省略
}

Tagを取得する際、親のUserも同時に取ってくるようなクエリを作ってみましょう。

private static void selectTagWithUser(final EntityManager em) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<Tag> query = builder.createQuery(Tag.class);
    final Root<Tag> root = query.from(Tag.class);

    root.fetch(Tag_.user, JoinType.LEFT); // 関連エンティティを同時に取ってくるように指定

    final List<Tag> result = em.createQuery(query).getResultList();
    for (final Tag tag : result) {
        System.out.println(tag.getUser());
    }
}

9行目がポイントです。実はこの行がなくても関連エンティティは取得できるのですが、SQLの実行回数が格段に変わってきます。俗に言う「N+1問題」を回避する手法です。

関連先のエンティティの条件を指定する

JPAの強力な機能の１つに、関連先エンティティの条件指定がとても簡単な点があります。

private static void selectTagByUserName(final EntityManager em, final String pUserName) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<Tag> query = builder.createQuery(Tag.class);
    final Root<Tag> root = query.from(Tag.class);

    query.where(builder.equal(root.get(Tag_.user).get(User_.name), pUserName));

    final List<Tag> result = em.createQuery(query).getResultList();
    for (final Tag tag : result) {
        System.out.println(tag);
    }
}

6行目がポイントです。「Tagクラス#userプロパティ」→「Userクラス#nameプロパティ」とたどって条件指定しています。SQLで同じことをしようとするとJOINを書く必要があり手間がかかるところですが、JPAではかなりシンプルに書けることが分かります。

Where句に IN条件を指定する

IN条件は少し特殊な書き方をするのでハマることがあります。

private static void selectUsersByNames(final EntityManager em, final String... names) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<User> query = builder.createQuery(User.class);
    final Root<User> root = query.from(User.class);

    if (names != null && names.length > 0) {
        query.where(root.get(User_.name).in(names));
    }

    final List<User> result = em.createQuery(query).getResultList();
    for (final User user : result) {
        System.out.println(user);
    }
}

7行目でIN条件を指定しています。CriteriaBuilderを使わない点に注意してください。

また要素数が0の時の挙動は、残念ながらDB製品依存となるようなので、プログラムで明示的にチェックするのが無難でしょう。

Tupleを使って柔軟な結果を得る

Tupleという汎用クラスを使えばエンティティにとらわれない形でデータを取得できます。例えば、JOINを使って複数のテーブルからデータを取得しつつ集計するような用途に有用です。

ただし、型安全性が失われる点には注意が必要です。

private static void selectTupleWithJoin(final EntityManager em) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();

    // Tupleで結果を受け取る
    final CriteriaQuery<Tuple> query = builder.createTupleQuery();

    // Tagを主テーブルにする
    final Root<Tag> root = query.from(Tag.class);

    // JOINする
    final Join<Tag, User> join = root.join(Tag_.user);

    final Path<String> userName = join.get(User_.name);

    // ユーザ名で集計する
    query.groupBy(userName);

    // Userから特定のカラムのみ取得しつつTagのstarCountを合計する
    // 後で取り出しやすいように、カラムには別名を付けておく
    query.multiselect( //
            userName.alias("user_name") //
            , builder.sum(root.get(Tag_.starCount)).alias("tag_count") //
    );

    final List<Tuple> result = em.createQuery(query).getResultList();
    for (final Tuple e : result) {
        System.out.println(e.get("user_name") + " " + e.get("tag_count"));
    }
}

任意のデータクラスをクエリの結果の型にする

Tupleの弱点は、Tupleが汎用的すぎて「どんなデータがいくつ入っているか分かりにくい」ことです。これを補うために、任意の型をクエリの結果とすることができます。

Tupleの例を書き直してみます。まずは結果を受け取るためのクラスを作ります。コンストラクタで全ての値を受け取るようにする必要があります。

public class StarSummary {

    private final String userName;
    private final long   tagCount;

    public StarSummary(final String pUserName, final long pTagCount) {
        this.userName = pUserName;
        this.tagCount = pTagCount;
    }

    // getterは省略
}

作ったクラスをクエリの結果とするには、CriteriaBuilder#construct(Class, Selection<?>...)を使ってクエリを組み立てます。

    private static void selectStartSummary(final EntityManager em) {
        final CriteriaBuilder builder = em.getCriteriaBuilder();
        final CriteriaQuery<StarSummary> query = builder.createQuery(StarSummary.class);
        final Root<Tag> root = query.from(Tag.class);

        final Join<Tag, User> join = root.join(Tag_.user);

        query.select( //
                builder.construct(StarSummary.class //
                , join.get(User_.name) //
                , builder.sum(root.get(Tag_.starCount)) //
        ));
        query.groupBy(join.get(User_.name));

        final List<StarSummary> result = em.createQuery(query).getResultList();
        for (final StarSummary e : result) {
            System.out.println(e);
        }
    }

9〜11行目でデータクラスを扱っています。

Tupleに比べ扱いやすい型で結果を得られますが、一方でコンストラクタ引数の順番に依存するプログラムとなってしまうのが弱点です。ですがTupleの「どんなデータがいくつ入っているか分かりにくい」という欠点はとても重大ですので、できれば、こちらのデータクラスを使う方が望ましいです。

型安全になりきれていない箇所

ここまで見てきたように、Criteria APIは型安全にクエリを組み立てられる非常に便利な機能なのですが、残念ながら型安全になりきれていない箇所があります。代表的なのはCriteriaBuilder#equal(Expression<?> exp, Object value)メソッドです。

例えば次のコードを見てください。

    query.where( //
        builder.equal(root.get(User_.name), pUserName) //
    );

これを次のように書き間違えたとしても、コンパイルエラーにはならないのです。

    query.where( //
        builder.equal(root.get(User_.id), pUserName) //
    );

このケースでは実行時例外がスローされますが、場合によっては例外がスローされず普通に実行されてしまうため、分かりにくいバグの原因となる可能性があります。

このメソッドのシグニチャが

<C> Predicate equal(Expression<C> exp, C value)

となっていればよかったのに・・・と思えてなりません。頻繁に使うメソッドだけに残念です。

JPAのその他の機能

最後に、ちょっとした便利機能をいくつか紹介しておきます。

ページングに使える２つのメソッド

Webアプリケーションでは検索結果が大量になる場合、ページング表示するのが普通です。JPAには簡単にページングを実装するためのメソッドがあります。

setFirstResult()/setMaxResults()です。

private static List<User> selectUsersWithPaging(final EntityManager em, final int pPageIndex, final int pCountPerPage) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<User> query = builder.createQuery(User.class);
    query.from(User.class);
    return em.createQuery(query) //
            .setFirstResult(pPageIndex * pCountPerPage) //
            .setMaxResults(pCountPerPage) //
            .getResultList();
}

7行目と8行目でページングを指定しています。

結果が必ず1件と分かっている場合に使えるメソッド

結果が必ず1件と分かっている時にはgetSingleResult()メソッドが使えます。

private static void countAllUsers(final EntityManager em) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<Long> query = builder.createQuery(Long.class);
    final Root<User> root = query.from(User.class);

    query.select(builder.count(root));

    final long count = em.createQuery(query).getSingleResult().longValue();
    System.out.println(count);
}

ただし、結果が1件でなかった時は例外がスローされますので、絶対に1件と確信が持てる場合にのみ使ってください。

 まとめ

Criteria APIを中心に、２回に渡ってJPAの様々な機能を解説してきましたがいかがでしたでしょうか。

JPAには他にも便利で重要な機能がたくさんあります。特にエンティティクラスの設計は工夫のしがいがあり、別の機会でご紹介したいところです。

非常にパワフルなJPA。JavaEEを使う場合はぜひJPAを使って効率的かつ安全にDBアクセスを実装していただきたいと思います。

JPAとは

JPAは一言で言えば「高機能なDBアクセスフレームワーク」です。DBアクセスフレームワークは実に様々なものがありますが、JPAの特徴は

• エンティティクラスへの操作を通してDB操作を実現する（DBの都合はプログラマから極力隠される）
• 型安全を追求するための様々な機能を備える

が挙げられます。Javaの良さを引き出す工夫に満ちたフレームワークと言えるでしょう。

様々な機能を備えたJPAですが、本エントリでは、検索、中でもCriteria APIを使った型安全な検索を中心にご紹介します。コードをしっかり載せていきますので、Criteria APIのコンセプトを感じ取っていただけると思います。

なお、JPAを動作させる環境を構築する方法は「JavaEEだけでここまでできる！GlassFish+Eclipseで高速Webアプリ開発【環境構築編】」をご覧下さい。

準備１・メタモデルクラスを自動生成する設定

メタモデルクラスとは、エンティティクラスのプロパティに関する情報を表すクラスであり、型安全にJPAを使うためには欠かせないクラスです。

例えば次のようなエンティティクラスがあったとしましょう。

package sandbox.entity;

import javax.persistence.Column;
import javax.persistence.Embedded;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    Long      id;

    @Column(length = 150, unique = true, nullable = false)
    String    name;

    // getter/setterは省略
}

このエンティティクラスに対するメタモデルクラスは次のようになります。

package sandbox.entity;

import javax.annotation.Generated;
import javax.persistence.metamodel.SingularAttribute;
import javax.persistence.metamodel.StaticMetamodel;

@Generated(value="Dali", date="2016-02-12T22:59:19.623+0900")
@StaticMetamodel(User.class)
public class User_ {
	public static volatile SingularAttribute<User, String> name;
	public static volatile SingularAttribute<User, Long> id;
}

メタモデルクラスはeclipseのような開発環境に自動で作ってもらうことができますので、有効にしておきましょう。

ecliseの場合の手順を紹介しておきます。プロジェクトのプロパティを開き、「プロジェクト・ファセット」から「Convert to faceted form…」をクリックします。

プロジェクト・ファセットが有効になったので、JPAサポートを有効にします。

ここで「 OK」を押していったんプロパティ画面を閉じます。

再びプロパティ画面を開くと「JPA」という設定項目が増えていますので、メタモデルクラスの自動生成を有効にします。

これで、エンティティクラスに変更が入る度にメタモデルクラスが自動生成されます。メタモデルクラスの名前はエンティティクラスの名前の後ろに _ を付けたものになります。

準備２・SQLをコンソールに出力する設定

JPAを使いこなすコツはJavaコードを中心に考えることですが、さすがにSQLが見えないと辛すぎます。せめてコンソールにSQLを出力するようにしておきましょう。JPAの設定ファイルであるpersistence.xmlにプロパティを追記します。

EclipseLinkの場合

<property name="eclipselink.logging.level.sql" value="FINE" />
<property name="eclipselink.logging.parameters" value="true" />
<property name="eclipselink.logging.logger" value="org.eclipse.persistence.logging.DefaultSessionLog"/>

OpenJPAの場合

<property name="openjpa.Log" value="DefaultLevel=WARN, Runtime=INFO, Tool=INFO, SQL=TRACE"/>
<property name="openjpa.ConnectionFactoryProperties" value="PrintParameters=true" />

APサーバにGlassFishを使っているのであれば、EclipseLinkの方を設定してください。

スキーマ定義をエンティティクラスで行う

JPAの良さを引き出すコツは、Javaコードを中心に考えることです。まずはスキーマ定義をエンティティクラスで行うようにしてみましょう。

ただ、実はJPAの仕様にはエンティティクラスからDDLを作る機能は含まれていません。JPAの実装であるEclipseLinkやOpenJPAの機能を使います。通常、persistence.xmlにプロパティを追記します。

EclipseLinkの場合

<property name="eclipselink.ddl-generation" value="create-tables" />

OpenJPAの場合

<property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema(ForeignKeys=true)" />

APサーバにGlassFishを使っているのであれば、EclipseLinkの方を設定してください。

Criteria APIによる検索

JPAの検索には、JPQLとCriteria APIの２つのやり方があります。JPQLは文字列でクエリを記述するため、コンパイル時に型チェックが全く働きません。

例えば以下のコードは実行時にClassCastExceptionがスローされてしまいます。

private static void selectByJPQL(final EntityManager em) {
    final String q = "select e from Tag e";
    for (final User user : em.createQuery(q, User.class).getResultList()) {
        System.out.println(user);
    }
}

よく見ると、クエリ文字列がfrom Tagとなっています。結果のエンティティはUser型で受けていますから、型が異なっていおり、実行時にClassCastExceptionがスローされるのです。

しかしCriteria APIを使うと、このようなミスはコンパイル時に検出できるようになります。上のJPQLをCriteria APIで描き直してみましょう。

private static void selectByCriteria(final EntityManager em) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<Tag> criteria = builder.createQuery(Tag.class);
    criteria.from(User.class);

    final TypedQuery<User> query = em.createQuery(criteria);
    for (final User user : query.getResultList()) {
        System.out.println(user);
    }
}

eclipseでこのコードを書くと、以下のようにコンパイルエラーとしてミスを教えてくれます。

このように、Criteria APIを使うとクエリのミスをコンパイル時にチェックできるようになります。これがCriteria APIの最大の利点です。

また、副次的な効果ですが変なクエリが書かれないようになります。実際の開発現場では、変態的なSQLが横行してチューンングの足枷になったり、特定のDB製品でしか実行できない書き方がされていたりと、SQL周りの問題が起きやすいです。しかしCriteria APIを使えばクエリの記述方法がある程度統一されるため、問題が起きにくく、またレビューしやすくなります。

Criteria APIによるクエリの基本形

Criteria APIはJPQLの構造をJavaクラスで表現したものと考えることができます。JPQLの構成要素の基本は次の３つです。

1. from句：どのエンティティ（≒テーブル）からデータを取得するか
2. where句：抽出条件
3. select句：どのエンティティ、あるいはプロパティなどを取得するか

この３つを踏まえると、Criteria APIを使ったプログラムの基本形は次のようになります。

private static void selectUsersByName(final EntityManager em, final String pUserName) {
    // クエリを組み立てるためのオブジェクトを得る
    final CriteriaBuilder builder = em.getCriteriaBuilder();

    // クエリ全体を表現するオブジェクトを作成.
    // 引数として、クエリ結果の型を指定する.
    final CriteriaQuery<User> query = builder.createQuery(User.class);

    // from句指定
    final Root<User> root = query.from(User.class);

    // where句指定
    query.where( //
            builder.equal(root.get(User_.name), pUserName) //
            , builder.isNotNull(root.get(User_.name)) //
    );

    // select句指定.
    // ここではプロパティではなくエンティティそのものを指定.
    // ただしfromと同じエンティティを指定する場合はこの行は省略可能.
    query.select(root);

    // クエリ実行
    final List<User> result = em.createQuery(query).getResultList();
    for (final User user : result) {
        System.out.println(user);
    }
}

結果の型を指定できるのがとても強力です。例えば全件数を得るクエリは次のように書けます。

private static void countAllUsers(final EntityManager em) {
    final CriteriaBuilder builder = em.getCriteriaBuilder();

    // 件数なので結果は数値で得るようにする
    final CriteriaQuery<Long> query = builder.createQuery(Long.class);
    final Root<User> root = query.from(User.class);

    // count関数を使う
    query.select(builder.count(root));

    final long count = em.createQuery(query).getSingleResult().longValue();
    System.out.println(count);
}

基本編はここまでです。次回の応用編では、Criteria APIの実戦的な機能をご紹介します。

前段・WebSocketはなぜ生まれたか

伝統的なWebアプリケーションは、HTTPというプロトコルで成立していました。HTTPとは単純なリクエスト・レスポンスモデルであり「クライアントであるWebブラウザがWebサーバに対してリクエストを投げ、返って来たレスポンスを処理する」というモデルで成り立っていました。あくまでクライアントが処理の起点となっているのです。

一方、Webアプリケーションであっても「サーバ側で起きた何らかの出来事を、Webブラウザに通知したい」というニーズは常にありました。これを「サーバプッシュ」と言います。これまで、HTTPを使って擬似的なサーバプッシュを実現するために技術者は様々な工夫を凝らしてきました。しかしやはり、リクエスト・レスポンスモデルの下では無理があったのです。

このような経緯があり、Webブラウザでの真のサーバプッシュを実現するべく策定されたのがWebSocketというプロトコルです。

もちろんJavaEEでもWebSocketはサポートされています。

本エントリではJavaEE7で導入されたWebSocketサーバを簡単に実現する機能をご紹介します。

最小のサンプル

これまで紹介してきたように、JavaEEでは、ある機能を使うのにアノテーションを付与したクラスを単に作成するだけで良い、というスタイルが広く採用されています。WebSocketも例外ではありません。

下記は最小のサンプルです。

package sandbox.websocket.minimum;

import javax.websocket.OnMessage;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/ws/min")
public class MinimumEndpoint {

    @OnMessage
    public String onMessage(final String pText) {
        System.out.println(pText);
        return "Re: " + pText;
    }
}

@ServerEndpointアノテーションを付けたクラスはWebSocketサーバとなります。このようなクラスをEndpointクラスと呼びます。

さらに@OnMessageアノテーションでクライアントから送信されたメッセージを処理するメソッドを指定しています。メッセージの処理内容は、送信されたメッセージの頭に「Re: 」を付けて送り返しています。

このクラスのテストのために、次のようなHTMLを作ってみましょう。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>WebSocket最小のサンプル</title>
  </head>
  <body>
    <input type="text">
    <button type="button" class="btn btn-primary form-control">送信</button>
    <script src="https://code.jquery.com/jquery-2.2.0.min.js"></script>
    <script>
       var ws = null;
       var onOpen = function() {
           $('button').click(function() {
               ws.send($('input').val());
           });
       };
       var onMessage = function(e) {
           alert(e.data);
       };
       var connect = function() {
           ws = new WebSocket('ws://localhost:' + location.port + '/ws/min');
           ws.onopen = onOpen;
           ws.onmessage = onMessage;
       };
       connect();
    </script>
  </body>
</html>

テキストフィールドに文字を入力して「送信」ボタンを押すと、先頭に「Re: 」を付けた文字列がアラートで表示されるサンプルです。

いかがでしょうか。いとも簡単にWebSocketを使ったアプリケーションが作れてしまうことが分かっていただけたかと思います。

ただ、このサンプルはWebブラウザからのリクエストが起点であるため、Ajaxでも実現可能でありWebSocketの旨味がないサンプルです。そこで以降では、WebSocketを使うための実践的な機能を紹介していきます。

@OnMessage以外のアノテーション

@OnMessageアノテーションの他にも@OnOpen/@OnError/@OnCloseというアノテーションがあり、これらのアノテーションが付与されたメソッドは、適切なタイミングでJavaEEコンテナから呼び出されるコールバックメソッドとなります。

下記に典型的なEndpointクラスの宣言方法を示します。

package sandbox.websocket.sample;

import javax.websocket.OnClose;
import javax.websocket.OnError;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/ws/sample")
public class SampleEndpoint {

    @OnOpen
    public void onOpen(Session pSession) {
    }

    @OnMessage
    public void onMessage(String pMessage) {
    }

    @OnError
    public void onError(Throwable pError) {
    }

    @OnClose
    public void onClose(Session pSession) {
    }
}

各メソッドはpublicである必要があります。

また@OnErrorコールバックメソッドは、Throwableを引数に取る必要があります。

それ以外のメソッドの引数は必要に応じて増減させることが可能です。例えば、@OnMessageのコールバックでSessionが必要なら、引数に追加してください。

URIテンプレート

接続先を分類するために、URLにパラメータを含めることが出来ます。

@ServerEndpoint("/ws/rooms/{room-descriptor}")
public class DescriptorEndpoint {
    ...

これを使うと、チャットルームの入室管理のようなことが比較的簡単に実装できます。簡単なチャットサーバのコードをご紹介します。

package sandbox.websocket.descritpor;

import java.io.IOException;

import javax.inject.Inject;
import javax.websocket.OnClose;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.PathParam;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/ws/rooms/{room-descriptor}")
public class DescriptorEndpoint {

    @Inject
    WebSocketSessionManager sessionManager;

    @OnOpen
    public void onOpen(@PathParam("room-descriptor") final String pRoomDescriptor, final Session pSession) {
        this.sessionManager.addSession(pRoomDescriptor, pSession);
    }

    @OnClose
    public void onClose(@PathParam("room-descriptor") final String pRoomDescriptor, final Session pSession) {
        this.sessionManager.removeSession(pRoomDescriptor, pSession);
    }

    @OnMessage
    public void onMessage(@PathParam("room-descriptor") final String pRoomDescriptor, final String pText) {
        for (final Session session : this.sessionManager.getSessions(pRoomDescriptor)) {
            try {
                session.getBasicRemote().sendText("Re: " + pText);
            } catch (final IOException e) {
                e.printStackTrace();
            }
        }
    }
}

注目していただきたいのは次の２点です。

• @ServerEndpointの引数にroom-descriptorというパラメータを含めている
• メソッドの引数に@PathParam("room-descriptor")を指定することでパラメータの値を得ている

なおEndpointクラスはCDIによるスコープ管理が効きません。たとえシングルトンな作りにしたくても、それが叶わないのです。

しかしインジェクション対象にすることはできます。ここでは、チャットルーム毎のWebSocket接続を管理するクラス（WebSocketSessionManager）をシングルトンとして作成し、@Injectアノテーションでインジェクションしています。

WebSocketSessionManagerクラスのコードも掲載しておきます。

package sandbox.websocket.descritpor;

import java.util.List;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.CopyOnWriteArrayList;

import javax.enterprise.context.ApplicationScoped;
import javax.websocket.Session;

@ApplicationScoped
public class WebSocketSessionManager {

    private final ConcurrentMap<String, Lock>          locks    = new ConcurrentHashMap<>();
    private final ConcurrentMap<String, List<Session>> sessions = new ConcurrentHashMap<String, List<Session>>() {
        public List<Session> get(final Object key) {
            List<Session> ret = super.get(key);
            if (ret == null) {
                ret = new CopyOnWriteArrayList<>();
                this.put((String) key, ret);
            }
            return ret;
        }
    };

    public void addSession(final String pRoomDescriptor, final Session pSession) {
        synchronized (this.getLock(pRoomDescriptor)) {
            this.sessions.get(pRoomDescriptor).add(pSession);
        }
    }

    public List<Session> getSessions(final String pRoomDescriptor) {
        return this.sessions.get(pRoomDescriptor);
    }

    public void removeSession(final String pRoomDescriptor, final Session pSession) {
        synchronized (this.getLock(pRoomDescriptor)) {
            this.sessions.get(pRoomDescriptor).remove(pSession);
        }
    }

    private Lock getLock(final String pRoomDescriptor) {
        final Lock newLock = new Lock();
        final Lock alreadyLock = this.locks.putIfAbsent(pRoomDescriptor, newLock);
        return alreadyLock == null ? newLock : alreadyLock;
    }

    private static class Lock {
        // nodef
    }

}

スレッドセーフにするために少し複雑なコードになっていますが、結局やっていることは部屋毎にWebSocket接続を束ねているだけなので、臆さず読み解いてみてください。

最後に、これをテストするためのHTMLを掲載します。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>WebSocket識別子のサンプル</title>
  </head>
  <body>
    <input type="text" name="desc" placeholder="部屋の識別子">
    <button type="button" class="connector">接続</button>
    <hr/>
    <input type="text" name="text" placeholder="送信テキスト">
    <button type="button" class="sender" disabled="disabled">送信</button>
    <hr/>
    <h3>レスポンス</h3>
    <p class="response"></p>
    <script src="https://code.jquery.com/jquery-2.2.0.min.js"></script>
    <script>
       var ws = null;
       $('button.connector').click(function() {
           if (ws) ws.close();
           var url = 'ws://localhost:' + location.port + '/ws/rooms/' + $('input[name="desc"]').val();
           ws = new WebSocket(url);
           ws.onmessage = function(e) {
               $('.response').text(e.data);
           };
           ws.onopen = function() {
               $('button.sender').removeAttr('disabled');
           };
           ws.onclose = function() {
               $('button.sender').attr('disabled', 'disabled');
           };
       });
       $('button.sender').click(function() {
            if (!ws || ws.readyState !== WebSocket.OPEN) {
               alert('先に接続して下さい。');
               return;
           }
           ws.send($('input[name="text"]').val());
       });
    </script>
  </body>
</html>

動作を見てみるときは、ぜひ複数のWebブラウザを開いてください。誰かの投稿が同じ部屋の全員に配信されることが分かると思います。とてもシンプルですが、チャットアプリケーションができました。

DecoderとEncoder

WebSocketはテキストデータとバイナリデータをやり取りできます。一般的には扱いやすいJSON形式のテキストを使うことが多いでしょう。しかしEndpointクラスを普通に作ると、@OnMessageコールバックの引数や戻り値の型は、単なるString型です。せっかくJavaを使っているのですから、ここはデータクラスに変換して型安全にメッセージを扱いたいものです。

この要求に応えるのが、Decoder/Encoderです。

Decoderクラス

Decoderクラスにはクライアント（一般的にはWebブラウザ）から送られてきたメッセージ内容を任意のJavaオブジェクトに変換する処理を実装します。このクラスを作成すると、Endpointクラスの@OnMessageコールバックメソッドに引数にString以外の型が使えるようになります。

ここでは ClientMessageというクラスを導入して、Decoderクラスを作ってみます。なおJSONとJavaオブジェクトの変換にはJSONICというライブラリを使っています。

まずはClientMessageクラスです。getterとsetterのみの単なるデータクラスとして作りましょう。

package sandbox.websocket.json;

import java.util.Date;

public class ClientMessage {
    private Date   date;
    private String body;
    // getter/setterは省略
}

次にDecoderです。JsonDecoderという名前で作ります。なお使い方は後で説明します。

package sandbox.websocket.json;

import javax.websocket.DecodeException;
import javax.websocket.Decoder;
import javax.websocket.EndpointConfig;

import net.arnx.jsonic.JSON;

public class JsonDecoder implements Decoder.Text<ClientMessage> {

    @Override
    public void init(@SuppressWarnings("unused") final EndpointConfig pConfig) {
        // nop
    }

    @Override
    public boolean willDecode(@SuppressWarnings("unused") final String pRequest) {
        return true; // デコード対象としない場合はfalseを返すが、通常はtrueでOK.
    }

    @Override
    public ClientMessage decode(final String pRequestJsonString) throws DecodeException {
        return JSON.decode(pRequestJsonString, ClientMessage.class);
    }

    @Override
    public void destroy() {
        // nop
    }
}

なおJSON文字列とJavaオブジェクトの変換にはJSONICというライブラリを使っています。

Encoderクラス

次にEncoderクラスを作ってみます。

Encoderクラスには、Javaオブジェクトをクライアントに送信するメッセージに変換する処理を実装します。このクラスを作成すると、Endpointクラスの@OnMessageコールバックメソッドの戻り値にString以外の型が使えるようになります。

ここではServerMessageというクラスを導入して、Encoderクラスを作ってみます。

ServerMessageクラスも、getterとsetterのみの単なるデータクラスとして作ります。

package sandbox.websocket.json;

import java.util.Date;

public class ServerMessage {
    private Date   date;
    private String body;
    private String senderSessionId;
    // getterとsetterは省略
}

次に、JsonEncoderを作りましょう。これも使い方は後で説明します。

package sandbox.websocket.json;

import javax.websocket.EncodeException;
import javax.websocket.Encoder;
import javax.websocket.EndpointConfig;

import net.arnx.jsonic.JSON;

public class JsonEncoder implements Encoder.Text<ServerMessage> {

    @Override
    public void init(@SuppressWarnings("unused") final EndpointConfig pConfig) {
        // nop
    }

    @Override
    public String encode(final ServerMessage pResponse) throws EncodeException {
        return JSON.encode(pResponse);
    }

    @Override
    public void destroy() {
        // nop
    }
}

DecoderとEncoderを使う

作成したDecoderとEncoderはEndpointクラスの中で使います。ポイントは次の２点です。

• Endpointクラスの@ServerEndpointアノテーションのdecodersとencodersに作ったクラスを指定
• @OnMessageコールバックメソッドの引数と戻り値にデータクラスを指定

それではサンプルコードを見てみましょう。

package sandbox.websocket.json;

import java.util.Calendar;

import javax.websocket.OnMessage;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint(value = "/ws/dec-enc" //
, decoders = JsonDecoder.class //
, encoders = JsonEncoder.class)
public class DecEncEndpoint {

    @OnMessage
    public ServerMessage onMessage(final Session pSession, final ClientMessage pRequest) {
        final ServerMessage ret = new ServerMessage();
        ret.setBody("Re: " + pRequest.getBody());
        ret.setDate(Calendar.getInstance().getTime());
        ret.setSenderSessionId(pSession.getId());
        return ret;
    }
}

String型がなくなり、データクラスを通して型安全にデータ操作ができるようになりました。

テスト用のHTMLも掲載します。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>Decoder/Encoderのサンプル</title>
  </head>
  <body>
    <input type="text" name="text" placeholder="送信テキスト">
    <button type="button" class="btn btn-primary form-control">送信</button>
    <script src="https://code.jquery.com/jquery-2.2.0.min.js"></script>
    <script>
       var ws = null;
       var onOpen = function() {
           $('button').click(function() {
               ws.send(JSON.stringify({ body: $('input[name="text"]').val() }));
           });
       };
       var onMessage = function(e) {
           alert(e.data);
       };
       var connect = function() {
           ws = new WebSocket('ws://localhost:' + location.port + '/ws/dec-enc');
           ws.onopen = onOpen;
           ws.onmessage = onMessage;
       };
       connect();
    </script>
  </body>
</html>

動作させてみると、JSON形式のデータをやり取り出来ていることが分かると思います。

データ変換の流れのまとめ

登場人物が多くなり少し複雑になったため、データ変換の流れを整理してみました。

変換処理の流れと、Decoder/Encoderがどのような役割を担っているかを理解いただけたでしょうか。

最後に

以上、JavaEEのWebSocketに関する機能をご紹介しました。

実戦ではもっとたくさんのことに気を配る必要があります。例えばエラー処理やスケーリング、認証、リクエスト内容の解析などの処理が必要です。

しかしWebSocketの根幹となる機能は、本エントリでご紹介した機能で充分カバーされていると思います。JavaEEで作るWebアプリケーションにもどんどんWebSocketを取り入れて、新しいユーザ体験を提供していきましょう。

APIはWebアプリケーションの用途を大きく広げる重要な要素であり、また、これをシンプルなインターフェイスであるREST形式で提供することは、より APIを利用しやすくするための重要な手法となっています。

本エントリではJavaEEでRESTインターフェイスを提供するための仕様であるJAX-RSをご紹介します。

JAX-RSとは

前述のように、RESTによるAPI提供の重要性は増すばかりです。JavaEEにおいても、JavaEE6からRESTインターフェイスを開発するための仕様であるJAX-RSが提供されるようになりました。

JAX-RSの特徴として、アノテーションを使ったシンプルな開発スタイルが挙げられます。まずは基本的な使い方を見てみましょう。

最小のサンプル

それではJAX-RSの最小のサンプルを作ってみましょう。JavaEEコンテナ環境下であれば、たった２つのファイルを作るだけで済みます。

JAX-RSの設定クラス

まずはJAX-RSの設定を持つクラスを作りましょう。

package sandbox.web.api;

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("/api")
public class RestApplication extends Application {
    // nodef
}

ポイントは２つ。

1. @ApplicationPath("/api")というアノテーションにより/api以下がJAX-RSで扱うURLになります
2. javax.ws.rs.core.Applicationクラスを継承します。

クラス名はどんな名前でも構いません。また実装は何も必要ありません。

リソースクラス

JAX-RSによる開発の主たる作業は、リソースクラスを作ることです。

リソースというのは情報の断片のことで、URLで識別されるものです。リソースクラスは、リソースに対する操作をリクエストに従って処理するクラスとなります。

ここでは次のような仕様のリソースを、リソースクラスで実装してみましょう。

• Hello, Worldというテキストをリソースとする
• /api/hello/textというパスに対するGETメソッドでテキストが得られる
• テキストのContent-Typeはtext/plain

クラス名は何でもいいのですが、ここでは分かりやすくHelloResourceとしましょう。

package sandbox.web.api;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/hello")
public class HelloResource {

    @Path("/text")
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String asText() {
        return "Hello, World";
    }
}

仕様がそのままアノテーションで表現されていますね。

ではブラウザで次のURLにアクセスしてみましょう。

次のような画面が表示されるはずです。

リソースクラスのポイント

JAX-RSの根幹、リソースクラスを詳しく見てみましょう。とはいえ非常に直感的なコードになっていますので、読み解きやすいと思います。

@PathアノテーションとURLの関係

クラスとメソッドに@Pathアノテーションを付与することで、このリソースクラスにアクセスするためのパス（≒URLの一部）を表現しています。

クラス宣言の@Pathアノテーションは、このリソースが/helloというパスで表されることを示しています。

@Path("/hello")
public class HelloResource

メソッド宣言の@Pathアノテーションは、このリソースに実際にアクセスするためのパスを示しています。

@Path("/text")
@GET
@Produces(MediaType.TEXT_PLAIN)
public String asText()

実際にアクセスするためのパスは、JAX-RSの設定クラスに付与した@ApplicationPathアノテーションにも影響されることに注意してください。

/api/hello/textというパスの階層毎に対応するアノテーションをまとめてみましたので、イメージしてみてください。

メソッドに付与された@GET/@Producesアノテーション

リソースクラスのメソッドには、@Pathの他にも２つのアノテーションが付いています。いずれも重要なアノテーションです。

@GETアノテーションは、メソッドが動作するHTTPメソッドがGETであることを示しています。HTTPメソッドに該当するアノテーションとして、他にも@PUT/@POST/@DELETEなどがあります。

@Producesアノテーションは、このメソッドが返す値をどのようなデータ形式で返すかを示していて、HTTP応答ヘッダ内のContent-Typeを指定していることに相当します。

このようにJAX-RSによるREST開発は、HTTPインターフェイスをアノテーションを駆使して表現するというスタイルになります。

それではJAX-RSが提供する様々な機能を見ていきましょう。多数の機能があるのですが、重要なものに絞ってご紹介します。

POSTメソッドに対応する

POSTメソッドでアクセスされた時に動くメソッドには@POSTアノテーションを付与します。

@Path("text")
@POST
public void postText(@FormParam("text") final String pText) {
    System.out.println(pText);
}

パラメータを@FormParamアノテーションで受け取っています。これは後ほど、もっと詳しく解説します。

同じ考え方で、PUTメソッドやDELETEメソッドにも対応できます。単に@PUTや@DELETEアノテーションを付与すればいいのです。直感的ですね。

@QueryParamアノテーションでクエリパラメータを受け取る

クエリパラメータとは、URLの?以降の部分を言います。例えば以下のURLのクエリパラメータはformat=jsonです。

http://example.com/api/hello/text?format=json

これをリソースクラスで受け取るには、メソッド引数に@QueryParamアノテーションを付与します。

@Path("/text-with-format")
@GET
@Produces(MediaType.TEXT_PLAIN)
public String getTextWithFormat(@QueryParam("format") final String pFormat) {
    return "Hello, World" + "(format=" + pFormat + ")";
}

ブラウザで次のURLにアクセスしてみてください。

確かにクエリパラメータが受け取れていますね。

@FormParamアノテーションでformのパラメータを受け取る

HTMLのformタグで送信するデータはapplication/x-www-form-urlencodedという形式であり、次のような書式のデータです。

param1=value1&param2=value2

JAX-RSではこの形式のデータは特別扱いであり、メソッドの引数に@FormParamアノテーションを付与することで値を受け取ることができます。

@Path("text")
@POST
@Produces(MediaType.TEXT_PLAIN)
public void postText(@FormParam("text") final String pText) {
    System.out.println(pText);
}

少し横道・JAX-RSのクライアントAPIによるテスト

RESTインターフェイスのテストを実施する際、GETであればブラウザで手軽にテストできますが、POSTやPUT、DELETEはそうはいきません。ところがJAX-RSにはクライアント用のAPIが備わっており、手軽にリソースクラスをテストすることができます。

JAX-RSのクライアント APIを使ってPOSTを送るサンプルを掲載しておきます。

public static void main(final String[] pArgs) {
    final Response response = ClientBuilder.newClient() //
            .target("http://localhost:8081/api") // 実行するWeb APIのエントリポイント
            .path("/hello/text") // リクエストを投げるURLのパス部分
            .request(MediaType.TEXT_PLAIN_TYPE) // 受け入れ可能なレスポンス形式(HTTPヘッダでいうAcceptに相当)
            // application/x-www-form-urlencoded形式でデータを作成(HTTPヘッダでいうContent-Typeに相当)し、リクエストを送信.
            .post(Entity.<String> entity("text=hoge", MediaType.APPLICATION_FORM_URLENCODED_TYPE));
    System.out.println(response.getStatusInfo());
}

パスパラメータを受け取る

URLの一部がパラメータになっているケースがよくあります。例えばよくあるブログエントリのURLがこれに相当します。

http://example.com/blog/2015/12/17

2015年12月17日のエントリという意味ですね。JAX-RSでこのようなパラメータを受け取るには、２つのアノテーションを併用します。

1. メソッドの@PathアノテーションでURLパラメータを表現
2. メソッド引数に@PathParamアノテーションを付与し値を受け取る

以下、サンプルです。

@Path("/date/{year}/{month}/{date}")
@GET
@Produces("text/plain; charset=UTF-8")
public String getDateText( //
        @PathParam("year") final int pYear //
        , @PathParam("month") final int pMonth //
        , @PathParam("date") final int pDate //
) {
    return String.format("%d年%d月%d日", pYear, pMonth, pDate);
}

@Pathアノテーションに{パラメータ名}というスタイルでパラメータを表現しているのが分かると思います。

ブラウザで次のURLにアクセスしてみてください。

HTTPリクエストのヘッダ情報を受け取る

時にはクライアントから送信されてきたHTTPヘッダの情報が必要な時があります。この場合、HttpHeaders型のメソッド引数を作り@Contextアノテーションを付与します。するとHttpHeadersを通してヘッダ情報が得られます。

@Path("/headers/{headerName}")
@GET
@Produces(MediaType.TEXT_PLAIN)
public String getRequestHeaderValue( //
        @PathParam("headerName") final String pHeaderName //
        , @Context final HttpHeaders pHeaders) {
    return String.valueOf(pHeaders.getRequestHeader(pHeaderName));
}

ブラウザで次のURLにアクセスしてみてください。

Servlet APIにアクセスする

リソースクラスの中でServlet APIにアクセスしたい場合、メソッド引数にServlet APIのオブジェクトを指定し、そこに@Contextアノテーションを付与します。

@Path("/text")
@GET
@Produces(MediaType.TEXT_PLAIN)
public String asText( //
        @Context final HttpServletRequest pRequest //
        , @Context final ServletContext pContext) {
    System.out.println(pRequest);
    System.out.println(pContext);
    return "Hello, World";
}

上記のように、HttpServletRequestとServletContextは取得可能ですが、HttpSessionはこの方法では取得できません。本来、RESTとHttpSessionは相容れないものですのでこの仕様は妥当と言えますが、どうしてもHttpSessionが必要な場合は、次のようにして取得してください。

@Path("/session-info")
@GET
@Produces(MediaType.TEXT_PLAIN)
public String sessionInfo(@Context final HttpServletRequest pRequest) {
    return String.valueOf(pRequest.getSession());
}

CDIの適用

リソースクラスはJavaEEコンテナ管理であるためCDI連携が可能です。ただ、CDI対象であることをコンテナに示すために、クラス宣言に@Dependentアノテーションを付与する必要があることに注意してください。

このことを踏まえると、リソースクラスは下記のようなコードになります。

@Path("/hello")
@Dependent
public class HelloResource {

    @Inject
    HogeService hogeService;

なおCDIの詳しいことについては本ブログの「JavaEE屈指の便利機能、CDIを触ってみよう」というエントリをご参照ください。

JSONでデータをやり取りする

最後に、実践的な内容としてJSONでデータをやり取りする方法をご紹介します。

昨今のWebAPIの多くはJSON形式でデータをやり取りしますが、JAX-RSはデフォルトではJSONを扱えません。多少の設定追加が必要ですので、この章で見て行きましょう。

データ変換用のクラスを作成する

JAX-RSには、Content-Typeに応じてJavaオブジェクトを変換する処理を選択／実行する機能が備わっています。

ここではContent-Typeがapplication/jsonの時に動作する変換用クラスを作成します。MessageBodyReaderとMessageBodyWriterインターフェイスを実装し、@Providerアノテーションを付与するのがポイントです。

実装すべきメソッドは５つあります。各メソッドの意味はコメントに書いておきました。どれも引数が多く見にくいかもしれませんが、実際のメソッドの中身はどれも１行ですので、臆さず読んでみてください。

package sandbox.jax_rs;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.lang.annotation.Annotation;
import java.lang.reflect.Type;

import javax.ws.rs.Consumes;
import javax.ws.rs.Produces;
import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.MultivaluedMap;
import javax.ws.rs.ext.MessageBodyReader;
import javax.ws.rs.ext.MessageBodyWriter;
import javax.ws.rs.ext.Provider;

import net.arnx.jsonic.JSON;

@Provider
@Consumes(MediaType.APPLICATION_JSON) // リクエストのContent-Typeがapplication/jsonの時に当クラスが実行される
@Produces(MediaType.APPLICATION_JSON) // レスポンスのContent-Typeがapplication/jsonの時に当クラスが実行される
public class JsonConverter implements MessageBodyReader<Object>, MessageBodyWriter<Object> {

    /**
     * クライアントに返すデータの長さを返しますが、不明な場合は-1を返します.
     */
    @Override
    public long getSize(final Object pT, final Class<?> pType, final Type pGenericType, final Annotation[] pAnnotations, final MediaType pMediaType) {
        return -1;
    }

    /**
     * クライアントから送られてきたデータのContent-Typeが、このクラスで処理可能かどうかを返します. <br>
     * このクラスの場合、application/jsonを処理するようにします.
     */
    @Override
    public boolean isReadable(final Class<?> pType, final Type pGenericType, final Annotation[] pAnnotations, final MediaType pMediaType) {
        return pMediaType.isCompatible(MediaType.APPLICATION_JSON_TYPE);
    }

    /**
     * クライアントに送り返すデータのContent-Typeが、このクラスで処理可能かどうかを返します. <br>
     * このクラスの場合、application/jsonを処理するようにします.
     */
    @Override
    public boolean isWriteable(final Class<?> pType, final Type pGenericType, final Annotation[] pAnnotations, final MediaType pMediaType) {
        return pMediaType.isCompatible(MediaType.APPLICATION_JSON_TYPE);
    }

    /**
     * クライアントからのデータをJavaオブジェクトに変換して返します. <br>
     * ここではクライアントからのデータをJSONと決め打ちして処理します. <br>
     */
    @Override
    public Object readFrom(final Class<Object> pType, final Type pGenericType, final Annotation[] pAnnotations, final MediaType pMediaType,
            final MultivaluedMap<String, String> pHttpHeaders, final InputStream pEntityStream) throws IOException, WebApplicationException {
        return JSON.decode(pEntityStream, pType);
    }

    /**
     * Javaオブジェクトを変換してクライアントに返します. <br>
     * ここではJSONに変換します. <br>
     */
    @Override
    public void writeTo(final Object pT, final Class<?> pType, final Type pGenericType, final Annotation[] pAnnotations, final MediaType pMediaType,
            final MultivaluedMap<String, Object> pHttpHeaders, final OutputStream pEntityStream) throws IOException, WebApplicationException {
        JSON.encode(pT, pEntityStream);
    }
}

なおこJSONとJavaオブジェクトの変換にはJSONICというライブラリを使っています。

リソースクラスでJSONレスポンスを返す

それではリソースクラスにJSON形式でデータを返すメソッドを追加しましょう。

@Path("/json")
@GET
@Produces(MediaType.APPLICATION_JSON)
public Map<String, Object> asJson() {
    final Map<String, Object> ret = new HashMap<>();
    ret.put("response", "Hello, World");
    return ret;
}

@Produces(MediaType.APPLICATION_JSON)というアノテーションにより、レスポンスをJSON形式にすることを示しています。

それではブラウザで次のURLにアクセスして下さい。

レスポンスがJSON形式のデータであることや、レスポンスヘッダのContent-Typeがapplication/jsonになっていることが確認できます。

リソースクラスでJSONを受け取る

次にJSON形式のデータをPOSTで受け取るメソッドを作ってみましょう。

@Path("/json")
@POST
@Consumes(MediaType.APPLICATION_JSON)
public void postJson(final Map<String, Object> pJson) {
    System.out.println(pJson.get("request"));
}

@Consumes(MediaType.APPLICATION_JSON)というアノテーションで、リクエストのContent-Typeがapplication/jsonである場合にこのメソッドが動作することを示しています。

クライアントAPIで動作確認をしてみましょう。

public static void main(final String[] pArgs) {
    final Response response = ClientBuilder.newClient() //
            .target("http://localhost:8081/api") //
            .path("/hello/json") //
            .request() //
            .post(Entity.<String> entity("{ \"request\": \"This is json request.\" }", MediaType.APPLICATION_JSON));
    System.out.println(response.getStatusInfo());
}

このメソッドを実行すると、リソースクラスのpostJson()メソッドが動作することが確認できるはずです。

まとめ

駆け足でJAX-RSを見てきました。実にシンプルな上、RESTの考え方にマッチした分かりやすい仕様になっているため、学びやすいと思います。

本エントリでは紹介しきれなかった機能の中には、サブリソースやキャッシュ制御、レスポンスの詳細な制御など重要なものがあります。幸い、オライリーから良いJAX-RSの指南書が出ています。分量が少なく読みやすいため、ぜひご一読をおすすめします。

冒頭に書いたように、Web APIの重要性は増すばかりです。JAX-RSを使ってRESTフルなAPIをどんどん開発し、Webサービスの価値を高めましょう。

マネジメントコンソールよりRDSを選択

RDSをクリック。

今すぐ始めるをクリック

DBの選択をする

データベースを選択する。

※今回はpostgreSQLを選択

立ち上げるRDSインスタンスを本番用で立ち上げるかを問われます。

今回は無料枠を使用したいので”いいえ”にチェックをつけて”次のステップ”をクリック。

RDSの詳細設定

各種設定を行います。

※DBインスタンスのクラスはテスト用なので一番小さいプランにしてます。

VPCセキュリティグループをデフォルトを選択。

DBの名前を決めます。

バックアップの保存期間などは後からでも変更可能です。

DBインスタンスの作成をクリックしてインスタンスを立ち上げましょう。

DBインスタンスを作成中となります。

DBインスタンスの表示をクリックしてみましょう。

ステータスが作成中となっていますね？

5分ほど待っていると、、、

ステータスが”利用可能”になりました。

これでもうpostgreSQLが使えるようになりました。

せっかくなので作ったdbに接続してみます。

pgAdminでDB(RDS)に接続

pgAdmin はhttp://www.pgadmin.org/からインストールできます。

pgAdminを起動したらファイル→サーバーの追加を選択。

RDSのダッシュボードにてDB インスタンスのエンドポイントが記載されています。

それをpgAdminのダイアログのホストへ入力します。

※コロンとポート番号は含めない

先ほど決めたユーザー名、パスワード、port番号を入力します。

OKを選択。

接続されるとDBが追加されます。

※server dosen’t listenとエラーになる場合はRDSのセキュリティグループで5432のポートを開放しましょう。

なお、本エントリではJavaEE7に搭載されているCDI1.1を前提とします。JavaEE6はCDI1.0となり、本エントリのコードに一部動作しなくなる箇所がありますのでご注意ください。

CDIとは

CDIとは、JavaEE6から採用された、JavaEEにおけるDI機能のことです。DIについての詳しいことはこちらのエントリをご覧いただくとして、本エントリではCDIの特筆すべき機能に焦点を当てることにします。

CDIの真髄・スコープ管理

CDIの真髄はインスタンスの存命期間、すなわちスコープを管理してくれることです。

Webアプリケーションを作っていると「このオブジェクトの持つ情報をしばらくの間保持したままにしておきたい」と思うことがあります。例えば次のようなケースです。

設定ファイルの内容

Webアプリ起動中は不変な情報であり、一度ファイルから読み込んだ内容をメモリにキャッシュして読み取り専用情報として使いたい。いわゆるシングルトンとして扱いたい。

DBに格納されたコードテーブル（コード値をラベル文字列に変換するテーブル）の内容

変更される可能性があるが、だからと言って頻繁に使う処理だから毎回DBにアクセスするのは遅すぎる・・・リクエストの先頭でまとめてDBから読み込んでリクエスト中のみ有効なキャッシュとしたい。

CDIがない場合

CDIなしに前述のような要求を実現するのは不可能ではありませんが、とても間違えやすく、また変更しにくいプログラムが必要です。試しにリクエスト単位で動作するカウンターを持つクラスを作ってみましょう。

まずはServletです。

@WebServlet(urlPatterns = "/cdi-sample")
public class CDISampleServlet extends HttpServlet {

    @Override
    protected void doGet(final HttpServletRequest pReq, final HttpServletResponse pResp) throws ServletException, IOException {
        ScopedService.Factory.get(pReq).countUp();
        ScopedService.Factory.get(pReq).countUp();
        pResp.setContentType("text/plain");
        pResp.getWriter().println("Counter Value -> " + ScopedService.Factory.get(pReq).getCounter());
    }
}

次にServletから使うServiceです。

public class ScopedService {

    private int counter = 0;

    public void countUp() {
        this.counter++;
    }

    public int getCounter() {
        return this.counter;
    }

    public static class Factory {

        public static ScopedService get(final HttpServletRequest pReq) {
            final String KEY = ScopedService.class.getName();
            ScopedService ret = (ScopedService) pReq.getAttribute(KEY);
            if (ret == null) {
                ret = new ScopedService();
                pReq.setAttribute(KEY, ret);
            }
            return ret;
        }
    }
}

いかがでしょうか？確かにこれで「リクエスト単位で状態を保持する」という要求を実現できたのですが、かなりいや〜な感じの実装になっていますね。

• ScopedService.Factory.get()メソッドの実装が煩雑。そもそもこんなメソッドを作らないといけないのが手間
• もしスコープに変更が入ったら・・・例えばシングルトンに変更する場合、マルチスレッドに気を払いながらScopedService.Factory.get()メソッドの中を修正する必要がある

これをCDIを使って書き換えてみましょう。

CDIがある場合

まずServletです。

@WebServlet(urlPatterns = "/cdi-sample")
public class CDISampleServlet extends HttpServlet {

    @javax.inject.Inject
    ScopedService scopedService;

    @Override
    protected void doGet(final HttpServletRequest pReq, final HttpServletResponse pResp) throws ServletException, IOException {
        this.scopedService.countUp();
        this.scopedService.countUp();
        pResp.setContentType("text/plain");
        pResp.getWriter().println("Counter Value -> " + this.scopedService.getCounter());
    }
}

@Injectアノテーションが最大のポイントです。このアノテーションが付いているインスタンス変数には、CDIが適切なオブジェクトをDIしてくれます。

次にServletから使うServiceです。

@javax.enterprise.context.RequestScoped
public class ScopedService {

    private int counter = 0;

    public void countUp() {
        this.counter++;
    }

    public int getCounter() {
        return this.counter;
    }
}

こちらは@RequestScopedアノテーションが最大のポイントです。このアノテーションが付いているクラスのオブジェクトは、CDIにより同じリクエスト内では使い回されます。つまりこのクラスのオブジェクトはリクエストスコープになるわけです。

そしてアノテーションが付いている以外は、ごくごく普通のクラスになりました。

スコープを変更する

CDIのすごいところは、アノテーションを変えるだけでスコープを簡単に変えることができる点です。先ほどのScopedServiceをリクエストスコープからアプリケーションスコープ（＝シングルトン、Webアプリ中に１つしかないオブジェクト）に変更してみます。

@javax.enterprise.context.ApplicationScoped
public class ScopedService {

    private int counter = 0;

    public void countUp() {
        this.counter++;
    }

    public int getCounter() {
        return this.counter;
    }
}

全コードを掲載するのはバカバカしいのですが、あえて掲載しました。変わったのは先頭のアノテーションのみです。

たったこれだけでスコープが変わりました。Servlet側は何も変更していません。すごいですね。

少し複雑な話・スコープの短いオブジェクトのDIがなぜ可能か

さて、CDIの凄さを知るために、少し複雑な話をします。

これまでの例では、何気なくServletにリクエストスコープのServiceをDIしていました。Servletはアプリケーションスコープで動作します。そこにリクエストスコープのオブジェクトをDIして、正しく動作するのでしょうか？

結論から言うと、もちろん正しく動作します。CDIはこのようなケース、つまり自身よりスコープの短いオブジェクトをDIするケースでは、「プロキシ」というオブジェクトを生成し、その中で適切に処理対象を振り分けるのです。

裏でこれだけのことをやってのけるCDIですが、使う側はアノテーションを付けるだけ！

驚異の高機能をごく簡単な記述で使う・・・CDIってすごいですね。

@Injectの別の付け方

ここまで@Injectアノテーションはインスタンス変数に付けていましたが、コンストラクタやsetterに付けることも出来ます。この場合、DIしたいオブジェクト引数に取るようにします。次の例はコンストラクタに付ける場合のサンプルです。

@WebServlet(urlPatterns = "/cdi-sample")
public class CDISampleServlet extends HttpServlet {

    private final ScopedService scopedService;

    @javax.inject.Inject
    public CDISampleServlet(final ScopedService pScopedService) {
        this.scopedService = pScopedService;
    }

    @Override
    protected void doGet(final HttpServletRequest pReq, final HttpServletResponse pResp) throws ServletException, IOException {
        this.scopedService.countUp();
        this.scopedService.countUp();
        pResp.setContentType("text/plain");
        pResp.getWriter().println("Counter Value -> " + this.scopedService.getCounter());
    }
}

こちらの方がテストしやすくなるため、より望ましいと思います。

CDIの美点

スコープ制御が不要に

これまで見てきた通り、スコープ制御のための複雑なコードが不要になります。

クラスの実装がシンプルに

スコープ制御のコードがなくなり、クラスには本来の処理のみを記述すればよくなります。これによりコードがシンプルになります。

テスタビリティが向上

これはCDIというよりはDIの美点です。

@Injectを付けておくと、実行時に適切なオブジェクトを生成／注入（＝インジェクション）してくれるのがDIの機能ですが、これによりnewを書かずに済み、状況に応じたオブジェクトの差し替えが可能になります。このためテスト用のモックを適用しやすくなり、テスタビリティが向上します。

この辺りの話は「newの連鎖」という言葉で解説されているWebページがありますので参考にしてください。

CDIのその他の機能

CDIには他にも便利な機能が多数あります。中でも有用な２つの機能をご紹介します。

AOPインターセプター

メソッドの前後に任意の処理を織り込むことをAOP、織り込む処理のことをインターセプターと言います。CDIでは簡単にインターセプターを作ることができます。

インターセプターを作るには次の２つのモジュールを作成します。

1. アノテーション：メソッドにどのインターセプターを適用するか、というマーカーとなるアノテーションを作ります。
2. インターセプタークラス：メソッドの前後に織り込む処理を実装します。

ここではメソッドの名前と実行後の戻り値を、コンソールに表示するインターセプターを作ってみます。

マーカーとなるアノテーション

package javaee.sandbox.interceptor;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import javax.interceptor.InterceptorBinding;

@InterceptorBinding
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
public @interface MethodPrint {
    // nodef
}

マーカーとなるアノテーションはほとんどん場合このパターンで実装できます。

インターセプタークラス

package javaee.sandbox.interceptor;

import javax.enterprise.context.Dependent;
import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;

@Interceptor
@MethodPrint
@Dependent
public class MethodPrintInterceptor {

    @AroundInvoke
    Object intercept(final InvocationContext pContext) throws Exception {
        System.out.println(pContext.getMethod().getName() + "メソッド実行開始.");
        final Object ret = pContext.proceed();
        System.out.println(pContext.getMethod().getName() + "メソッド実行終了. 戻り値 -> " + ret);
        return ret;
    }
}

型宣言に付いた２つのアノテーション、@Interceptorと先に作ったマーカーとなるアノテーション（@MethodPrint）がポイントです。@Interceptorにより、このクラスがインターセプタークラスであると宣言しています。また@MethodPrintにより、どのマーカーアノテーションに反応するのかを示しています。

織り込む処理はメソッドとして実装します。次のようなルールで作成します。

• @AroundInvokeアノテーションを付与
• 名前は何でもい
• 戻り値はObject型
• 引数はInvocationContext型１つのみ
• 本来のメソッドを実行するにはInvocationContext#proceed()メソッドを実行

ここでは、本来のメソッドの実行前後にコンソール表示を行っています。また、InvocationContext#proceed()メソッドの戻り値は本来のメソッドの戻り値です。場合によってはこの戻り値を加工して差し替える、などということも可能です。

beans.xmlに追記

インターセプターを使うにはbeans.xmlにクラス名を書いておく必要があります。beans.xmlはWEB-INFディレクトリ直下に起きます。内容は以下のようにします。

<?xml version="1.0" encoding="UTF-8"?>
<beans bean-discovery-mode="annotated"
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd">

    <interceptors>
        <class>javaee.sandbox.interceptor.MethodPrintInterceptor</class>
    </interceptors>

</beans>

<class>タグにインターセプタークラスのフルネームを書きます。

インターセプタークラスを使う

インターセプターで処理を織り込みたいメソッドにマーカーとなるアノテーション（ここでは@MethodPring）を付与するだけで使えます。例を見てみましょう。

import javaee.sandbox.interceptor.MethodPrint;

import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class ScopedService {

    private int counter = 0;

    public void countUp() {
        this.counter++;
    }

    @MethodPrint
    public int getCounter() {
        return this.counter;
    }
}

たったこれだけです。簡単ですね。このクラスを実行すると、コンソールに次のように表示されます。

getCounterメソッド実行開始.
getCounterメソッド実行終了. 戻り値 -> 4

@PostConstruct

この機能は便利・・・と言うより知らないと困るかもしれません。CDIで管理されるオブジェクトの初期化タイミングで何か処理をしたい、というのはよくあることです。例えば設定ファイルの中身をロードしてキャッシュしておく、というケースです。しかし、コンストラクタでは初期化できないことが多いです。コンストラクタの中ではDI対象のフィールドが初期化されていないことが多いからです。例えば下記のようなケースです。

@ApplicationScoped
public class NonInitializationService {

    @Inject
    ConfigurationLoader               loader;

    private final Map<String, String> configurationCache;

    public NonInitializationService() {
        // 下記はNG.
        // コンストラクタの中では this.service が null なので.
        this.configurationCache = this.loader.loadConfiguration();
    }
}

このような場合に使えるのが@PostConstructアノテーションです。このアノテーションを付けたメソッドは、全てのDIが完了した後に呼び出されますので、初期化処理には最適です。先ほどの例は次のように書き直すとうまく動作します。

@ApplicationScoped
public class InitializationService {

    @Inject
    ConfigurationLoader         loader;

    private Map<String, String> configurationCache;

    @PostConstruct
    void postConstruct() {
        this.configurationCache = this.loader.loadConfiguration();
    }
}

 詳しい文献

本エントリではCDIを凝縮したエッセンスをご紹介しました。さらに詳しい情報を得たい方のために文献をご紹介しておきます。

Oracleによるチュートリアル（英語）

こちらのページへどうぞ。

日本語での説明

Qiitaの記事「JavaEE使い方メモ（CDI）」が最も詳しいと思われます。

まとめ

CDIのもたらすインパクトは大きいものです。アノテーションさえ付ければスコープ管理のための余計なコーディングが必要なく、コアな実装に集中することができます。結果、テストのしやすさや変更のしやすさ、コードの見通しの良さなど、様々な恩恵が得られるはずです。

うまく使って楽にWebアプリケーションを開発しましょう。

キャンパスサイズを変える

コンテンツに応じて塗りつぶしを使いこなせ！

コンテンツに応じたパッチも覚えちゃおう！

まとめ　使い分けの秘訣

• 「コンテンツに応じて塗りつぶし」→周囲のパターンを読み取って、カンバスの広げた部分のみ塗りつぶす。（元の画像には影響は無い）ある程度は複雑な背景でも適用できる。うまくいかないときは「コンテンツに応じたパッチツール」を使うのも良い。

•  「コンテンツに応じて拡大縮小」→人物など保護をかけたもの以外の背景を拡大縮小。背景の画質は少々落ちる。

物によってどれが合うか違いますので色々試してみてください。

基礎的なことかもしれませんが、画像のサイズを変えることが出来ればデザインの幅がひろがります。これでちょっと足りないを乗り切ってくださいね。

今回の写真はフリー写真素材ぱくたそ さんの素材を使わせていただきました。