2016年9月27日火曜日

【JavaでPlayFramwork2.4.6】routesファイル

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

ただ今、もうすぐ始まるプロジェクトの実装で使用するPlayFrameworkについて事前勉強を進めています。


今回はURLを制御するroutesファイルについてご紹介します。

伝説のXML地獄


JavaWebシステム業界では長年の間、Struts1が支配的な地位を占めてきました。
そこで常に大問題を起こしてきたのが「struts-config.xml」「web.xml」という巨大XMLです。

コイツラはWebシステムが受け付けるURLを制御したり、そのリクエストを行った際に取得するパラメータを格納するFormや、遷移先のjspなど、WebシステムのWeb部分を管轄する設定ファイル達です。

欠点は、もの凄く煩雑なんですよね!!

基本的にココで躓くのは新人レベルの人なのですが、XMLなんでちょっと壊れただけでも動かなくなりますし、設定が間違っていても動かないし、ログを追うのも難しいし、と不慣れな若手プログラマーの未来の芽を摘むのに多大な役割を果してきました。

更にORMappingにSpringとHibernateを導入すれば完璧。

今やJavaWebシステム業界の金字塔とも言える究極のXML地獄が完成します。

これね、慣れれば分かるんですよ。でも不慣れだと全然分からない。
だから自分が数年の月日を経て手慣れてきても、その頃には会社には後輩が入ってきているわけで、「何か動かないんですけど~」と単体環境で起動も出来ないような始末になっていることは日常茶飯事。

あのXML地獄は最悪だとみんな身に染みて分かっているんですね。
そうして出てきた概念が、あの有名なRubyOnRailsのキャッチフレーズ、

「設定より規約」

です。

一言で言いますと、「ファイル名、クラス名を合わせておけばXMLは省略出来るよ」というものです。

RubyOnRailsの命脈を引き継ぐPlayFramworkもこの思想がありまして、膨大な設定ファイルを多数記述しなくても、ある程度の命名規約に則してソースを作っておくだけでとりあえず動いてくれる。

もう「設定より規約」はRubyOnRailsがどうこうと言うより、Webシステム業界の基本概念と言って良いくらいになってきましたね。

今回はPlayFramworkでURL制御をする為のやり方を検証してみたいと思います。

コントローラ


まず最初にリクエストを叩いた直後に呼び出されるクラス「コントローラ」を作成します。

public class LoginController extends Controller {
 /**
  * @return Result
  */
 public Result index() {

  Form userForm = Form.form(LoginForm.class);

  return ok(views.html.layout.login.render(userForm));
 }

}


命名規約と言っておいてなんですが、実際には「Controllerクラスを継承する」という点だけ守っておけばOKです。

しかし、ここで特徴が一つ。
コントローラを格納するcontrollersパッケージはルート直下に置くのがオススメです。


普通はJavaのパッケージって言うと組織を表現する長~いフルパスを指定するものじゃないですか?
弊社ジェニシスで言えば「jp.co.net.genesis.controllers」というパッケージにするのがJava業界のお約束ですが、PlayFrameworkはいきなり「controllers」だけにするのが普通です。

理由は後述します。

routesファイル


クラスを作ったところで、次にURLの定義に移ります。

上記「LoginController」のメソッド「index」とURLリクエストを結びつけるには、confフォルダ配下のroutesファイルに以下のように記述すればOKです。


GET     /                           controllers.LoginController.index()
GET     /login/                           controllers.LoginController.index()


見た目そのままかと。簡単ですね。

RubyOnRailsと違い「LoginというURLを打ち込めば自動的にLoginクラス」という挙動はありません。
「設定より規約」の思想を受け継ぎつつも、この辺りは「規約より設定の方が便利」という崩しが入っているんですね。

ほら、上記の例だと「URLに何も入力しなかったら自動的にログインを表示」という挙動も簡単に表現できます。
このくらいが自動化するのに丁度良い塩梅だと考えたのでしょう。

また、従来のStruts1のAction方式が「1URL1アクションクラス」だったのに対し、PlayFrameworkのコントローラはメソッド分けにも対応しています。
なのでクラス数が膨大に増えていってしまう問題が解消されている一方、URL設計をちゃんとやらないと1クラスにメソッドが大量終結してしまう欠点があります。
この辺りは設計者の腕の見せ所ですね。

しかし、ここで注意事項。

  • controllers.LoginController.index()

「controllers」という文字がありますね。そう、このroutesファイルの記述はフルパスなんですよ。
これが上記でルート直下をオススメした理由です。

もし「jp.co.net.genesis.controllers」と書いてしまうと、記述がこうなります。

  • jp.co.net.genesis.controllers.LoginController.index()

長いんですよ。
もちろん1システムにURL数は数十~数百まで沢山ありますから、もし会社名まで含めたパッケージにしてしまうと、routesファイルは以下のようになってしまいます。


  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()

これは冗長でしょう!!

気にしなければ良いと言えばそれだけなのですが、PlayFrameworkは軽快にアプリケーションを作っていくという思想がありますから、「フルパスがどれだけ長かろうがコピペするだけなんだから作業効率は変わらん」ということは分かりつつも、
出来るだけ記述する文字数を減らすのがPlayFramework。

伝統的なJavaエンジニアにはちょっと気持ち悪いですが、ここはルートフォルダ直下にcontrollersパッケージを置くのがPlayFrameworkの標準かな、という所感です。

終わりに


これでURL制御は終わりです。
PlayFrameworkの簡単さがよく分かる一例だったと思います。

引き続きPlayFrameworkの検証を進めます。

2016年9月20日火曜日

【JavaでPlayFramwork2.4.6】ログ出力とフィルター

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

業務多忙により更新が停滞していましたが、再びPlayFrameworkの連載を復活します。

ログ出力

システムを構築する時に最初にどこから作っていくか、というところは個人の趣味があるところかと思いますが、私の場合はまずログ出力から固めていきます。
今回はログ出力についてご紹介します。

出力本体

PlayFrameworkのログ出力と銘打ってこんな記事を書いていますが、PlayFrameworkはJavaを内包していますから、早い話が単なるLog4jなんですよね。


PlayFrameworkの中には最初からLog4jが入っていますので、素直にコレを使えば良いかと。
log4jの標準に従ってlogback.xmlを設置すればその通りに動いてくれるようになります。

この辺りはPlayFrameworkの話ではなくlog4jそのままの話ですので、この記事でわざわざ記述するほどの話ではないかと。

今回はここから一歩踏み込みまして「リクエストの開始と終了のログ」を出力する方法に行ってみたいと思います。

ロギングフィルター


純粋なJavaのフレームワークであれば、リクエストの開始と終了は「doGet」とか「doPost」のメソッドの最初と終了にログを出力するようAbstractの親クラスを作るだけの話ですが、PlayFrameworkはそういう風に出来ていませんのでちょっとしたコツが必要になります。

そのテクニックを「フィルター」と言います。


フィルターとは、前回でご紹介したGrobal.javaに適応するものでして、
全てのリクエストの開始時に呼び出される共通処理を提供する機能です。

使い方はGrobal.javaのメソッド「filters()」にフィルタークラスをセットするだけでOKです。

 /**
  * Get the filters that should be used to handle each request.
  */
 @Override
 public  Class[] filters() {

  Class[] clazz = new Class[1];
  clazz[0] = RequestLogFilter.class;

  return clazz;
 }

これで全てのリクエストの開始時に「RequestLogFilter」が呼び出されますので、そこにログ出力の処理を書けば良いわけですね。
ただし、Filterはscalaで書かなければなりません。

PlayFrameworkでJavaを選択したプロジェクトであってもFilterクラスはscalaのみなのでご注意を。

しかしですので、Filterというのは開始時に呼び出されるものであって、終了時には呼び出されません。
よって「リクエストの終了ログはどうやって出すの?」という問題が発生します。

これにつきましてもPlayFrameworkとscalaならではの機能で実現してくれます。

traitとインターセプター


以下が私が使用しているログフィルターです。

class RequestLogFilter extends EssentialFilter {

  def apply(nextFilter: EssentialAction) = new EssentialAction {

    def apply(requestHeader: RequestHeader) = {

      def isTarget = RequestLogFilterUtils.isLonningTarget(requestHeader.uri);

      val startTime = System.currentTimeMillis

      if (isTarget) {
        Logger.info(RequestLogFilterUtils.getStartLog(requestHeader.method, requestHeader.uri))
      }

      nextFilter(requestHeader).map { result =>

        val requestTime = System.currentTimeMillis - startTime

        if (isTarget) {
          Logger.info(RequestLogFilterUtils.getEndLog(requestHeader.method, requestHeader.uri, result.header.status, requestTime))
        }

        result.withHeaders("Request-Time" -> requestTime.toString)

      }

    }

  }

}


RequestLogFilterUtilsというのは、私はscalaが不見識ですので文字列加工機能部分だけJavaに切り出しているだけなので気にする必要はありません。
今回のポイントはこちら。

nextFilter(requestHeader).map { result =>


nextFilterです。

resultという単語が出ていることから察せられるとおり、この中身がリクエストの終了時に呼び出されることになります。

?????

Javaエンジニアには意味不明な機構ですね。

これはscalaが搭載している「trait」という機能でして、Javaで言うところのインターフェースに近い性質を持つものです。
ただし、インターフェースほどカッチリとはしておらず、より柔軟性を持たせたものである模様。

ともかく、流れたとしては、

  1. リクエストが来る。
  2. リクエストをフィルターでインターセプト(傍受)する。
  3. リクエストにフィルターで定義した機能を挟み込む。

こういうちょっとメタっぽい形でリクエストにフィルター機能を持たせます。

そして開始ログを提供するメイン部分は普通にそのまま実行。
終了ログ部分は「trait」を使って定義しておいて、リクエスト終了時に後から呼び出す(chainするように)ようにフィルターの親クラスである「EssentialFilter」が作られている、とこういう構図なようです。

むむ。
これはPlayFrameworkの中でもかなりscala寄りの部分なようですね。
本格的に理解を深めるにはscalaの勉強を深めなければならなさそうですが、この連載は「JavaでPlayFramwork」なので掘り下げはこの辺り留めたいと思います。

終わりに


引き続きPlayFrameworkの勉強を進めます。

2016年7月25日月曜日

【JavaでPlayFramwork2.4.6】Grobal.java

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近はPlayFrameworkについて勉強を進めています。

前回まででプロジェクトの作成に成功したところで、今回はいよいよ細かい機能の確認に入っていきたいと思います。
今回のテーマは「Grobal.java」です。

Grobal.java


公式の参考ページは以下です。


上記はバージョンPlay2.3の話です。
本ブログで取り扱うのは2.4.6ですが、公式そのものが枯れていないので公式に無い話を取り扱うのもやむなし。
頑張っていきましょう。

役割


まず、Grobalクラスの役割は全てのコントローラクラスの総合継承クラスとでも言いましょうか。
本来コントローラが担当するURLリクエスト活動の親クラスとしての他、システムの初回起動時専用など全体的な共通処理を担当するクラスです。

従って、

  • システム初回起動時に一回だけ行いたい処理
  • 各URLのリクエスト時に毎回実行したい処理

この辺りがGrobalクラスの役割と言えるでしょう。

特徴


Grobalクラスの特徴は、やはりクラス名が「Grobal」であるということです。
「Grobal2」とかちょっとクラス名を変えただけで動きません。
そう、Grobalクラスは、場所がルート直下で、クラス名がGrobal.javaであるというネーミング規約があります。

後は、「GlobalSettingsクラス」を継承しているという点くらいでしょうか。

public class Global extends GlobalSettings {


私が特徴に思うのは、やっぱり「Grobal.java」であることというネーミング規約が敷かれている点でしょうか。
「Grobal2」とかちょっとでも違うネーミングにするともう動きません。

外部ファイル名ではなくJava本体のクラス名にこのような規約を設定するのはJavaプログラミングでは余り見かけない特徴だと思います。
この辺りがscalaベースとしているPlayFramworkの特徴でしょう。

このように、JavaがJavaクラスのクラスやメソッドを「文字列として認識」して振り分けるという機能を「リフレクション」と言います。

メタプログラミングと言い換えても良いでしょうか。

普通にシステム開発者として従事している間は余り需要はありあせんが、ライブラリ開発社の立場からすると偶に裏技として出番がある時があります。
「こういう使い道もある」という程度に覚えておくと良いかもしれませんね。


各メソッド


Global.javaが実現する機能は親クラスであるGlobalSettingsの実装に準拠しています。


public class GlobalSettings {

    /**
     * Executed before any plugin - you can set-up your database schema here, for instance.
     */
    public void beforeStart(Application app) {
    }

    /**
     * Executed after all plugins, including the database set-up with Evolutions and the EBean wrapper.
     * This is a good place to execute some of your application code to create entries, for instance.
     */
    public void onStart(Application app) {
    }

    /**
     * Executed when the application stops.
     */
    public void onStop(Application app) {
    }

    /**
     * Called when an exception occurred.
     *
     * The default is to send the framework's default error page. This is achieved by returning null,
     * so that the Scala engine handles the excepetion and shows an error page.
     *
     * By overriding this method one can provide an alternative error page.
     *
     * @param t is any throwable
     * @return null as the default implementation
     */
    public F.Promise onError(RequestHeader request, Throwable t) {
        return null;
    }

    /**
     * Call to create the root Action of a request for a Java application.
     * The request and actionMethod values are passed for information.
     *
     * @param request The HTTP Request
     * @param actionMethod The action method containing the user code for this Action.
     * @return The default implementation returns a raw Action calling the method.
     */
    @SuppressWarnings("rawtypes")
    public Action onRequest(Request request, Method actionMethod) {
        return new Action.Simple() {
            public F.Promise call(Context ctx) throws Throwable {
                return delegate.call(ctx);
            }
        };
    }

    /**
    *
    * Called when an HTTP request has been received.
    * The default implementation (return null) means to use the application router to find the appropriate action
    *
    * By overriding this method one can provide an alternative routing mechanism.
    * Please note, though, this API is very low level, useful for plugin/module authors only.
    *
    * @param request the HTTP request header as seen by the core framework (the body has not been parsed yet)
    * @return an action to handle this request - if no action is returned, a 404 not found result will be sent to client
    */
    public play.api.mvc.Handler onRouteRequest(RequestHeader request) {
        return null;
    }

    /**
     * Called when no action was found to serve a request.
     *
     * The default behavior is to render the framework's default 404 page. This is achieved by returning null,
     * so that the Scala engine handles onHandlerNotFound.
     *
     * By overriding this method one can provide an alternative 404 page.
     *
     * @param request the HTTP request
     * @return null in the default implementation, you can return your own custom Result in your Global class.
     */
    public F.Promise onHandlerNotFound(RequestHeader request) {
        return null;
    }

    /**
     * Called when an action has been found, but the request parsing has failed.
     *
     * The default behavior is to render the framework's default 400 page. This is achieved by returning null,
     * so that the Scala engine handles onBadRequest.
     *
     * By overriding this method one can provide an alternative 400 page.
     *
     * @param request the HTTP request
     * @return null in the default implementation, you can return your own custom Result in your Global class.
     */
    public F.Promise onBadRequest(RequestHeader request, String error) {
        return null;
    }

    /**
     * Get the filters that should be used to handle each request.
     */
    public  Class[] filters() {
        return new Class[0];
    }

}


メソッドを抜き出すと以下です。

  • beforeStart
  • onStart
  • onStop
  • onError
  • onRequest
  • onRouteRequest
  • onHandlerNotFound
  • onBadRequest
  • filters

色々ありますね……。

このうち、私が現在のシステム開発で必要としているのは以下です。

  • beforeStart:システム初回起動
  • onRequest:各種リクエスト実行時
  • filters:フィルター

beforeStartメソッドというのはシステムで最初にリクエストを受けた時だけ実行されるメソッドです。
シングルトンクラスの初期化などで実行するのが良いでしょう。

onRequestメソッドはリクエスト毎に毎回実行。

filtersメソッドは、onRequestに連動しているものです。

各種リクエストの開始終了ログなど、システムの最初に用意するログ機構についてはこの辺りが活躍するわけですね。

終わりに


次回はログ出力の手法についてご紹介したいと思います。

2016年7月4日月曜日

【JavaでPlayFramwork2.4.6】Eclipseへの取り込み

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近はPlayFrameworkについて勉強を進めています。

前回にて一応、プロジェクトの作成には成功しました。
次はEclipseへの取り込みに行ってみましょう。

開発環境はEclipse


まず大前提ですが、Javaで開発するんだからそりゃEclipse使いたいですよね?
と言いますのも、PlayFrameworkは根っこの思想がScalaなので、根本的には「Eclipseみたいな派手な総合開発環境(IDE)が無くてもテキストエディターだけで実装出来るよ」というものがあります。

いや、確かにそうなのかもしれませんけど、何をするにもやっぱIDEはあった方が良いと思います。

これは他の言語でも同じ。
PHPでもRubyでもその他でも、テキストエディターとかviとかだけで実装する熟練の戦士は確かに一定数いるとは聞きますが、今は文明の利器であるIDEがあるんだから使えばいいしょ。

「最近の若いもんはEclipseが無ければコード一つマトモに書けやしない……」

別にいいだろ! あるんだから使えば!!

と言う訳で、実装パワーをIDEに頼り切るスタイルは今後も継続です。

しかし、問題はどのIDEを使うか、ですね。

  • Eclipse
  • IntelliJ IDEA

ご存じのように、日本ではEclipseがぶっちぎりの一強、事実上のスタンダード。
しかし世界を見渡すとIntelliJ IDEAもなかなかのシェアを誇る。

最近はAndroidアプリ開発専用IDE「AndroidStudio」がIntelliJ IDEAのカスタマイズで作られている辺り、日本人でもIntelliJ IDEAを無視できなくなってきました。

「IntelliJ IDEAの方がEclipseより優れている部分もあるんだぜ!!」

みたいな話も調べると出てきますし、IntelliJ IDEAの習得は将来性を鑑みたJavaエンジニアの課題として一考に値するものだと言えるでしょう。

しかし、今回の所はEclipseでやらせて頂きたいと思います。
私自身がEclipseに慣れっこなのでEclipse以外は気が進まないというのもありますが、何より、私以外の要員も私と同じくEclipse派ばかりですので。
IntelliJ IDEAを導入するには説明出来るだけの合理性と、要員の教育、全員のモチベーションが必要で、そういった体制も考えるとEclipse以外の選択は厳しいのです。

プロジェクトのインポート

では、さっそくEclipseに取り込んでいきましょう。
前回までで「Activator new」で作ったプロジェクトをEclipseのworkspace配下に置いて、プロジェクトを取り込みます。

当然ながら、Eclipseの「プロジェクトの作成」で作るわけでは無いということです。

結果がこちら。


この時点ではプロジェクトにEclipse設定ファイルがありませんので、ご覧のようにJavaプロジェクトではなくファイル一覧のように見えてしまっています。

これをEcipseに対応させるには、Play公式にやり方が掲載されています。


まずプラグイン「sbteclipse」を入れます。project/plugins.sbt に以下の記述を入れるだけでOK。

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "4.0.0")

この『プラグイン』というものに他にどんなものがあるのか、探していくのも面白そうですね。

次に、Activatorで「Eclipse」というコマンドを発行します。


すると、以下のようにプロジェクトにクラスパス等が通ってすっかりJavaプロジェクト風になりました。


特にエラーも起きていませんね……。
おかしいな……。

いえ、実はですね、私が最初に行った時はここまでやってもEclipseにエラーが発生していたのです。
原因はこちら。


赤枠の部分。

  • target/scala-2.11/twirl/main
  • target/scala-2.1.1/routes/main

これが自動的に入ってくれないのでscalaクラスの変数がコンパイルエラーを起こすというものがあったのです。


Application.javaの変数「index」が変数解決不能のエラーを起こしていたら、それはソースフォルダに「scala-2.11/twirl/main」「scala-2.1.1/routes/main」が入っていないことが原因だから手動で追加しろという内容の記事を書こうと思っていたんですが……。

ちくしょー。
私が最初に検証を行っていた4月の頃から今記事を書いている7月の現時点まででこの問題が解消されてやがる。

だからこれからPlayを始める人はこんなことに悩まなくて良いんだ……。

すいませんね。
私は画像キャプチャを取る為に過去に行った作業を一からやり直しながら記事を執筆しており、当時存在していたEclipseコマンドのバグがいつの間にか修正されていることに今気付いたのですよ。

ここまで書いて記事を消すのも悲しいので、本日はこれにて終了……。

PlayFramworkは非常にホットなライブラリなので、過去にあった問題がサラッと直っていることもあるということです。

終わりに


やられましたね、これは!!

しかし過去に存在した問題がアップデートで解決するのは望ましいこと。
Tacyは人柱になったと思って祈りを捧げて下さい。

引き続きPlayの連載を継続します。

2016年6月20日月曜日

【JavaでPlayFramwork2.4.6】ビルド時のネットワーク問題と起動

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近はPlayFrameworkについて勉強を進めています。

プロジェクト起動


前回の荒技で、とにかく2.4.6でのプロジェクトは完成しました。

では、プロジェクトの起動に行ってみましょう。

コマンドプロンプトを起動し、

cd "作成したプロジェクトのフルパス"
activator run

これでプロジェクトが起動します。
が、実際には私はここで躓いたので、その時の経験談も踏まえて今回は雑談ベースです。

Activatorにパスが通っていない


私のような慌て者のエンジニアは上記の通りActivatorコマンドを実行しても「操作可能なプログラムまたはバッチ ファイルとして認識されていません。」とか出てくるかもしれませんね。
これはActivatorにパスが通っていないのでしょう。

PlayFrameworkの管理コマンドであるActivatorはダブルクリックで自動インストールするものではなく、圧縮ファイルを展開して設置し、そこに手動でパスを通さなければいけないものです。
この状況に陥っている人は公式サイトをもう一度ご確認下さい。


ネットワーク問題


PlayFrameworkはActivatorコマンド実行時とrun実行時の二回に分けてインターネット上からファイルをダウンロードしてくる挙動となっています。
従ってネットワーク環境に繋がっていない環境では起動出来ません。

私はここで大変苦労しました。
私の現在の現場環境はセキュリティが大変厳しいので自由にインターネット接続出来ません。
よってsbtのビルドで自動であっちこっちからjarファイル等のライブラリをダウンロードしてくるのは望ましくなかった為、オフラインビルドを試みました。


公式サイトのダウンロードページに「Offline Distribution」というリンクがあり、これがsbt実行ダウンロードするファイルを最初から一塊で取得出来るものです。
これを取得し、USBメモリでオフラインPCに移動させて、いざオフラインPCから起動……とやってみたわけですが……。

結論を言うと、無理!!
初回のオフラインビルドは現実的ではありません。

と言いますのも、どうやら「Offline Distribution」と言えども全部入っているわけではないようです。
インターネット界は日々進化していますので、細かいバージョンの差分とかが発生してしまって「Offline Distribution」には既に古くなってしまったものが混ざっているのです。

また、「Offline Distribution」はあくまで初回セットであり、そこから追加で何かプラグインを入れたりするとなると、当然ながら「Offline Distribution」の中にはありません。

「Offline Distribution」に入っていないものは別途、手動でネットからダウンロードしてオフラインPCに移植し……と頑張ってみましたが、無理でした。
取得しなければならないファイルは一個や二個の話ではないので、手動ダウンロードを繰り返してビルドしようと思ったら一日では終わりません。

二日……三日……どれくらい頑張ったら出来るんだろう???

とにかく、インターネットビルドを使わず手動ビルドで初回起動するのは三途の川のほとりで石を積み上げるようなものです。

頑張ってもゴールに辿り着けませんので、これからビルドする人は絶対にインターネット環境でビルドすることをオススメします。

  • オフラインだけでのビルドは至難。オンライン環境は事実上の必須。
  • どうしてもオフラインでビルドしなければならない場合、最初だけオンラインでビルドし、ダウンロードしたファイルをオフラインPCに移植する。

ただし、あくまでも初回起動時にjarファイルを収集するステップが大変なだけですので、一度ビルド出来てしまえば、後はオフラインでもOKです。
複数人で作業する場合も、最初に一台だけインターネット環境でビルドし、集めたjarファイルをUSBメモリ等で他のオフラインPCに移植すれば、全部オフラインでも起動出来ます。

経験者ならではの体験談ですね。。。

プロキシ


当然ながら社内などプロキシがある環境で実行する場合、プロキシが通っていなければインターネットに接続出来ません。

これは知っている人は当然でしょうが、私は初体験でした。
インターネットオプションのプロキシと、コマンドプロンプトのプロキシは別です。

コマンドプロンプト実行時にプロキシ接続する場合は、例えば以下のようにコマンドラインからプロキシを設定するとか、
システム詳細の環境変数で事前にプロキシ設定を登録するといった対応の必要があります。

set HTTP_PROXY=http://プロキシサーバ:ポート番号/

この辺りはPlayの話というよりネットワークの問題ですので、各環境毎に奮闘願います。
簡単そうで意外に難しかったです。

起動成功

こうして環境の壁を越えて、何とかようやく初回起動出来ました。
「http://localhost:9000/」で以下のような画面が表示出来ます。


私の場合はネットワークの壁があったので大変苦労しましたが、それが無い環境でしたらスルッと簡単に起動まで辿り着けると思います。

やっぱり開発者には快適なインターネット環境は必要不可欠ですね。。。

終わりに


これにてようやく初回起動まで辿り着きました。
引き続き勉強を継続していきます。

2016年6月6日月曜日

【JavaでPlayFramwork2.4.6】プロジェクト作成 後編 ~古いバージョンで作成する~

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

業務都合によりPlayFramworkを始めました。
ここまでの下勉強により、PlayFramworkのバージョンは2.4.6にすることにしました。

しかし、PlayFramworkは最新バージョンで作成するのは簡単なのですが、古いバージョンで作成するのは面倒なのです。
今回は古いバージョンで作成する手順をご紹介します。

バージョン指定が出来ない


おさらいから行ってみましょう。
PlayFrameworkではプロジェクトを新規作成する場合、コマンドプロンプトでActivatorのnewコマンドを実行すれば一発で作成出来ます。

activator new my-first-app play-java

この時、Activatorはインターネットに接続し、Play本家のサイトから最新バージョンをサーチして取得するという挙動をします。
勝手に最新バージョンを取得してしまい、古いバージョンは取得出来ません。

「-version=2.4.6」のようにオプションを指定することで古いバージョンを取得する機能はありません。

これくらい出来そうな気がするんですけどね。何で無いんだろ……。

しかし、自動で作成出来ないなら手動で作成しましょう。

テンプレートをダウンロード


PlayFrameworkのnewコマンドが最新バージョンになってしまうのは、最新のテンプレートをダウンロードしてくるからです。
そして過去のテンプレートはGitHubに置いてありますので、これを手動でダウンロードすればテンプレートは入手可能です。

以下サイトからお好みのバージョンをダウンロードしてきてください。
私は2.4.6をダウンロードします。


解凍すると、中に「templates」というフォルダが入っています。


その中には2.4.6テンプレート4種が入っています。


これこれ、これが欲しかったんですよ。
私はJavaを使用しますので「play-java」をゲッツします。


その中身は、このように「Activator new」した時とほぼ同じ構成になっています。
PlayFramework初心者はこの状態からスタートするのが最もスムーズに入っていく近道でしょう。

しかし、この状態でアプリを起動しようとするとまだエラーが発生してしまいます。



  • :: org.scala-sbt#sbt;%SBT_VERSION%: java.lang.IllegalArgumentException at sun.net.www.ParseUtil.decode(ParseUtil.java:202)

%SBT_VERSION%!!

バージョン指定。
つまり、本来はnewコマンドが自動で行ってくれる設定ファイルへの最新バージョンセット機能が作動していない。
よってここから先は手動でバージョンを記述することになります。

「手動でセットって、どんな値をセットすればいいの?」という問題につきましては、フォルダを一個遡ってtemplatesフォルダ直下のbuild.sbtに書いてあります。

import play.sbt.activator.Templates._

templateSettings

scalaVersion := {
  // If we're a snapshot build, then default to 2.10.5, since this is what gets built by default for Play
  // If we're a production build, then we want 2.11.6
  sys.props.getOrElse("scala.version", if (isSnapshot.value) {
    "2.10.5"
  } else {
    "2.11.6"
  })
}

crossScalaVersions := Seq("2.10.5", "2.11.6")

templates := {
  val dir = baseDirectory.value
  Seq(
    "play-scala",
    "play-java",
    "play-scala-intro",
    "play-java-intro"
  ).map(template => dir / template)
}

version := sys.props.getOrElse("play.version", version.value)

def playDocsUrl(version: String) = {
  // Use a version like 2.4.x for the documentation
  val docVersion = version.replaceAll("""(\d+)\.(\d+)\D(.*)""", "$1.$2.x")
  s"http://www.playframework.com/documentation/${docVersion}"
}

// Use different names for release and milestone templates
def templateNameAndTitle(version: String) = {
  val officialRelease = version.matches("[0-9.]+") // Match final versions but not *-SNAPSHOT or *-RC1
  if (officialRelease) ("", "") else ("-preview", " (Preview)")
}

templateParameters := Map(
  "PLAY_VERSION" -> version.value,
  "SCALA_VERSION" -> scalaVersion.value,
  "PLAY_DOCS_URL" -> playDocsUrl(version.value),
  "SBT_VERSION" -> "0.13.8",
  "COFFEESCRIPT_VERSION" -> "1.0.0",
  "LESS_VERSION" -> "1.0.6",
  "JSHINT_VERSION" -> "1.0.3",
  "DIGEST_VERSION" -> "1.1.0",
  "RJS_VERSION" -> "1.0.7",
  "MOCHA_VERSION" -> "1.1.0",
  "ENHANCER_VERSION" -> "1.1.0",
  "EBEAN_VERSION" -> "1.0.0",
  "PLAY_SLICK_VERSION" -> "1.1.0",
  "TEMPLATE_NAME_SUFFIX" -> templateNameAndTitle(version.value)._1,
  "TEMPLATE_TITLE_SUFFIX" -> templateNameAndTitle(version.value)._2
)


パッと見て概ね意味は分かるのではないでしょうか?

例えば、「SBT_VERSION" -> "0.13.8"」と書かれていますので、
先ほどのエラーの「%SBT_VERSION%」の所には「0.13.8」を書けば良いという意味になります。

「"PLAY_VERSION" -> version.value」のように直球で書かれていない部分は、
「自分は2.4.6を使いたいんだから2.4.6だな」と判断していくことになります。

これらを元にplay-javaの以下ファイルにガンガン手動記述していってください。

  • play-java/build.sbt
  • play-java/project/build.properties
  • play-java/project/plugins.sbt

ちょっと数が多いので面倒ですが、正常に設定出来ていないと上記画像のようにコマンドプロンプト上にエラーが出来ますから、
地道にやっていけば10分くらいで起動まで到達出来ると思います。

これでPlayFramwork2.4.6の起動に成功しました。
おめでとうございます!!

終わりに


我ながら荒技ですね、このやり方は……。
元々がActivator newコマンド一発で可能な作業なわけですから、
build.sbtによるビルドを熟知している人なら、こんな手動置換作業を行わなくても自動でビルド出来るはずなのですが……。

しかし調べても分からなかったので今回はこのような手動ゴリ押し戦術で対処しました。

何か分かったら追加記事を書きたいと思います。

引き続きPlayFramworkの記事を継続します。

2016年5月30日月曜日

【JavaでPlayFramwork2.4.6】プロジェクト作成 前編

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

業務都合によりPlayFramworkを始めました。
ここまでの下勉強により、PlayFramworkのバージョンは2.4.6にすることにしました。

では、いよいよプロジェクトの新規作成に行ってみましょう。

Activatorのダウンロード

さて、PlayFrameworkの最初は「Activator」という管理ツールのダウンロードから始まります。
ダウンロードサイトはこちら。


しかしですね~、ここで一つ、驚きの事実が発覚します。


これね、2.2、2.3、2.4、2.5と色々とリンク揃ってるでしょ?
2.3~2.5は全部同じなんですよ。
何でこんなことになっとるんじゃ!!
ともかく、「よっしゃ。俺は2.4.6を使うから2.4.6をダウンロードするぞ!!」なんて指定には何の意味も無いのでどれでもいいから目に入ったヤツを適当にダウンロードしたってください。

しかし、2.2以前は違います。
前回の記事でPlayはバージョン毎の差異が結構あって、特に2.2と2.3の間の隔たりが大きいと書きましたが、その一番の理由がコレです。

「Activatorは2.3以降だけ。2.2以前はActivatorではない」

2.2までは「Playコマンド」っていう旧体系のものなのですね。

なのでコマンドプロンプトで「Play ……」ってやっているサイトが出てきたら、それは古い情報です。
2.3以降はこのActivatorコマンドを使用します。

Activatorのインストール

インストールについて特記事項は無いのでサラリと済ませましょう。
ダウンロードしたファイルを解凍して適当に置き、binフォルダに環境変数でパスを通せばOKです。

公式サイトにあるように済ませて下さい。


プロジェクト作成


Activatorにパスが通ったらプロジェクトの新規作成が可能になっています。
プロジェクトの作成は簡単です。
わざわざこのブログに記述せずとも公式サイトを見てそのままでOKかと思いますが、一応簡単にご紹介を。



プロジェクトを作成したい場所に移動し、コマンドプロンプトで「activator new」とすればプロジェクトの作成が始まります。


  • 1) minimal-akka-java-seed
  • 2) minimal-akka-scala-seed
  • 3) minimal-java
  • 4) minimal-scala
  • 5) play-java
  • 6) play-scala

「akka」というのはTypesafeが開発している並列分散フレームワークのakkaのことです。
並列分散?
つまり、サーバを1台、2台ではなく、ズラッと沢山並べて大規模処理を分散することを想定したフレームワークです。
今回は取り扱いませんが、こういうのもあるということだけ覚えておきましょう。

「minimal-java」は必要最小限のプロジェトの土台を作るだけのモード。
本当にちょろっとしか無いです。
詳しく知っている人ならともかく、初心者がここから構築していくのは無理じゃないかなぁ。

「play-java」はプロジェクトが一通り構築された状態から始められるコースです。
基本的にこの「play-java」を選ぶのが効率的スタートの起点となるでしょう。

なお、「scala」というのはJavaではなくscalaでプロジェクトを作るという意味です。
PlayFramworkはJavaでもslacaでもどちらでも使えるフレームワークですが、今回の連載はJavaで進行するので割愛。

では、play-javaを選んで次に進みます。

プロジェクト作成済み。しかし……


プロジェクト名は「play-sample」として、無事にプロジェクトが完成しました。


プロジェクト構成は一通り出来上がっており、「Hello World!」が表示可能状態です。
実に簡単ですね!!

しかし、ちょっと待って下さい。
「play-sample/project/plugins.sbt」を見ると以下のような記述があります。

  • addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.5.3")

そう、PlayFrameworkのActivatorは「自動的に最新バージョンを取得する」という仕様なのです。
つまり、このプロジェクトは「2.4.6」ではなく「2.5.3」で作られてしまっているわけです。

ここが最初の山場です!!

PlayFrameworkは最新バージョンで作成するのは簡単ですが、古いバージョンを指定して作る機能が見当たりません。

私もネットで散々探したのですが、どうやら「activator new version=2.4.6」みたいに簡単にスパッと作るコマンドは無いみたいなのです。

終わりに


次回後編は本番。

「PlayFrameworkを古いバージョンで始めたい場合にどうすれば良いのか?」


情報がどうしても見つからないので私が体当たりで編み出した荒技をご紹介します。