Secret Staircase

これまでにいくつかの Java 用のテンプレートエンジンを見てきました。今回はそれらを比較します。

対象

JSP (非 JSF)

Velocity

FreeMarker

Handlebars.java

Scalate (SSP)

評価軸

評価軸として優先度の高いものから順に以下を考えます。

デフォルト HTML エスケープ

レイアウト機能

HTML 以外での利用

デフォルト HTML エスケープ

デフォルトで HTML エスケープされない場合、<c:out\> や ${escape(...)} など明示的に書くことになりますが、書き忘れてしまう危険性があるのと、なにより書き忘れていないことの確認が大変難しいのが問題です。

デフォルトで HTML エスケープされる場合は、逆にエスケープしない箇所を ${unescape(...)} などと明示的に書くので、間違ってエスケープを外していないかこの箇所だけの確認で済みます。

テンプレートエンジンによっては特定のインターフェースを実装していたり、アノテーションが付いているなどクラス定義によりエスケープを回避できるものがあって、その場合も調べるのは容易です。Java のコードなので単体テストが書きやすい利点があります。

JSP

ELResolver を使ってデフォルトでエスケープすることができます。書き方にもよりますがエスケープできるのは String のみで、その他のクラスの toString の結果はエスケープされません。このような箇所の特定は非常に困難です。 検証記事

Velocity

ReferenceInsertionEventHandler を使ってデフォルトでエスケープし、テンプレートでの変数名やクラス定義によりエスケープを回避できます。後者だけに限定してテンプレート側からエスケープの制御をできないようにしてしまうのがテストの書きやすさやエスケープ漏れの防止の観点で効果的でしょう。 検証記事

FreeMarker

TemplateLoader をカスタマイズして自動的に <#escape> タグで囲むようにしてデフォルトエスケープを実現できます。検証記事

Handlebars.java

デフォルトで HTML エスケープされます。0.12.0 には JSP 同様に String 以外がエスケープされない問題がありますが新しいバージョンでは直っているはず。{{{ ... }}} や SafeString クラスを使ってエスケープを回避することができます。テンプレートでのエスケープ回避が簡単すぎるのと、記号を随時変更できるのでエスケープしていない箇所の特定が難しそうな点は気になります。検証記事

Scalate (SSP)

デフォルトで HTML エスケープされます。 検証記事

レイアウト機能

たいていのテンプレートエンジンは自前で何らかのレイアウト機能を持っています。不足の場合は Tiles や SiteMesh などのフレームワークを組み合わせても良いですが自前で簡単にセットアップできるのは強みです。

JSP

レイアウト機能はありません。

Velocity

標準ではありませんが SpringMVC と使う場合は VelocityLayoutView が使えます。

FreeMarker

マクロを使ってレイアウトを実現できます。参考サイト

Handlebars.java

Template Inheritance が使えます。他のテンプレートエンジンに比べて高機能です。

Scalate

標準でレイアウト機能があります。

HTML 以外での利用

Web アプリケーションではメール送信などでテンプレートエンジンを使う機会があるので、HTML 以外でも使えるとテンプレートエンジンを 1 つで済ませられるので便利です。

比較

以上の内容を表にしてみました。 (オリジナルサイズ)

Velocity が良いですね。レイアウトはそのままでもまずまずの機能がありますし、Tiles を使ったり自前の VelocityView を作って改善することも可能です。

Handlebars.java も優秀です。クライアントサイドで Handlebars を使う場合はテンプレート記法を統一できる利点もありますね。API も今風で使いやすいです。エスケープ回避の記法が自由すぎてエスケープしていない箇所を見つけにくいのが弱点で、この点をきっちりしたいなら Velocity の方がいいでしょう。

結論としては、安定指向なら Veolocity、高度なレイアウト機能やクライアントと同じ記法を使いたいなら Handlebars.java が良さそうです。

今回の観点では JSP を採用する理由はありません。(JSF はだいぶ違うのでこの限りではありません)

FreeMarker は Velocity と似ているので好みでどちらかを選べば良いでしょう。

Scalate は Java から使うときに多少の考慮が必要なので、素直に他の Java テンプレートエンジンを使った方が良いです。詳細

検証に使ったソースコードは github にあります

scala スクリプトでライブラリの依存性を解決して XML API を呼び出すということをやったのでメモ。

某勉強会の日程調整のために調整さん用の候補日を出力するスクリプトを作った。こんなのを出力する。

5/25 (土) 9:00 - 12:00 5/26 (日) 9:00 - 12:00 6/1 (土) 9:00 - 12:00 6/2 (日) 9:00 - 12:00 ...

scalas

スクリプトでライブラリの依存性を解決するために scalas を使う。詳しくは sbt のドキュメントがある。conscript を使った方法ではインストールできなかったので Manual Setup の項の方法で scalas ファイルを用意した。

$HOME/bin/scalas

java -Dsbt.main.class=sbt.ScriptMain \ -Dsbt.boot.directory=$HOME/.sbt/boot \ -jar `dirname $0`/sbt-launch.jar "$@"

スクリプト

祝日判定にはカレンダー API を使わせていただいた。

#!/usr/bin/env scalas // vim: ft=scala /*** scalaVersion := "2.10.1" libraryDependencies ++= Seq( "com.github.nscala-time" %% "nscala-time" % "0.4.0", "net.databinder.dispatch" %% "dispatch-core" % "0.10.0" ) */ import com.github.nscala_time.time.Imports._ import dispatch._, Defaults._ val from = LocalDate.today val to = from + 3.months def holidayApi(from: LocalDate, to: LocalDate) = { host("calendar-service.net") / "cal" <<? Map( "start_year" -> from.year.get.toString, "start_mon" -> from.month.get.toString, "end_year" -> to.year.get.toString, "end_mon" -> to.month.get.toString, "year_style" -> "normal", "month_style" -> "ja", "wday_style" -> "ja", "format" -> "xml", "holiday_only" -> "1" ) } def holidays(from: LocalDate, to: LocalDate) = { for { xml <- Http(holidayApi(from, to) OK as.xml.Elem) } yield { for { mday <- xml \\ "mday" year = (mday \ "@year").text.toInt month = (mday \ "@month").text.toInt day = (mday \ "@mday").text.toInt } yield new LocalDate(year, month, day) } } def isHoliday(holidays: Seq[LocalDate])(day: LocalDate) = day.dayOfWeek.get == 6 || day.dayOfWeek.get == 7 || holidays.contains(day) val hs = holidays(from, to)() Stream.iterate(from)(_ + 1.day). takeWhile(_ <= to). filter(isHoliday(hs)). map(_.toString("M/d(E)") + " 9:00-12:00"). foreach(println)

できた

... 6/29(土) 9:00-12:00 6/30(日) 9:00-12:00 7/6(土) 9:00-12:00 7/7(日) 9:00-12:00 7/13(土) 9:00-12:00 7/14(日) 9:00-12:00 7/15(月) 9:00-12:00 7/20(土) 9:00-12:00 ...

Tumblr の markdown 記法でリンクを

[ここ][1]をクリック! [1]: <http://www.yahoo.co.jp>

と書くと再編集したときに消えてしまって困ってたけど

[ここ](http://www.yahoo.co.jp)をクリック!

Handlebars.java は Handlebars の Java 実装です。

ここでは Template Inheritance 機能とデフォルト HTML エスケープの動きを中心に見てゆきます。

セットアップ方法 Handlebars.java のページが詳しいです。Spring MVC の ViewResolver も提供されています。検証に使ったソースコードも参考になると思います。

Template Inheritance

Handlebars.java では Template Inheritance 機能が使えます。親テンプレートで定義された複数のブロックを子テンプレートから上書くことができ、多くのテンプレートエンジンが単一のブロックのみの上書きをサポートしているのに対して、より柔軟なテンプレートを書くことができます。

親レイアウトとなる basic.hbs を用意します。

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <link rel="stylesheet" href="../../../stylesheets/bootstrap.min.css"> <title>{{#block "title"}}DEFAULT TITLE{{/block}}</title> </head> <body> {{> layout/navibar}} <div class="container"> {{#block "content"}}DEFAULT CONTENT{{/block}} </div> {{> layout/footer}} <script src="../../../javascripts/jquery-2.0.0.min.js"></script> {{#block "script"}}{{/block}} </body> </html>

3 つのブロックが定義されてて、これらを子テンプレートで上書きすることができます。

{{#block "title"}}DEFAULT TITLE{{/block}}

{{#block "content"}}DEFAULT CONTENT{{/block}}

{{#block "script"}}{{/block}}

次に、子テンプレート main.hbs を用意します。

{{#partial "title"}}andlebars{{/partial}} {{#partial "content"}} <article> {{#with wikiPage}} <h1>{{title}}</h1> <div>{{body}}</div> {{/#with}} </article> {{/partial}} {{#partial "script"}} <script> $('...').click(function() { ... }); </script> {{/partial}} {{> layout/basic}}

title, content, script を上書きしています。複数の変数を上書きできるのは多くのテンプレートエンジンでサポートされていますが、Template Inheritance ではこの例のように HTML のブロックで上書きできるので大変便利です。

デフォルト HTML エスケープ

Handlebars では何も設定しなくてもデフォルトで HTML エスケープされます。

前回までに使っていたのと同じモデルを使って動作を検証してみます。

WikiPage wikiPage = new WikiPage( "<strong>Tokyo</strong>", new WikiText("<strong>Tokyo</strong> is the capital of Japan."));

まず title の出力です。

エスケープできていますね。

続いて WikiPage の出力。

WikiPage#toString() の結果をエスケープできています。 現行バージョンの 0.12.0 は JSP と同様にエスケープされない問題があるのですが修正されたので次バージョンからは問題がありません。上記は 0.13.0-SNAPSHOT の結果です。JSP のは仕様だけど。

今度は明示的にエスケープを回避してみます。{{{...}}} を使うとエスケープなしで出力できます。{{..}} と間違えてしまいそう...。デリミタを変更することができるのでたとえば erb スタイルにすれば間違えにくくなるかもしれません。

{{=<% %>=}} escape: <% title %> noescape: <%{ title }%> <%={{ }}=%>

いずれにしてもエスケープしていない箇所を検出して警告する処理がビルドやデプロイプロセスにあった方が良さそうです。

クラス定義でエスケープを回避する機能として SafeString が用意されています。このクラスにラップした文字列はエスケープされません。

モデルクラスでこのように SafeString を返しておくとエスケープされません。

public Handlebars.SafeString getHandlebarsSafeString() { return new Handlebars.SafeString(getSafeHtmlValue()); }

これはオリジナルの JavaScript 版にならった挙動ですがインターフェースかアノテーションで指定できた方が便利かもしれませんね。

まとめ

Handlebars.java により流行の Mustache/Handlebars を Java でも使えるようになります。Template Inheritance が使え、デフォルトで HTML エスケープされ、機能的には十分に実践で使えるレベルにあるでしょう。

検証に使ったソースコードは github にあります

Scalate は Scala で書かれたテンプレートエンジン。Java から利用することも可能です。

Spring MVC から利用する

Spring MVC 用の ViewResolver が提供されています。依存ライブラリを pom.xml に書きます。

<dependency> <groupId>org.scala-lang</groupId> <artifactId>scala-compiler</artifactId> <version>2.10.1</version> </dependency> <dependency> <groupId>org.fusesource.scalate</groupId> <artifactId>scalate-spring-mvc_2.10</artifactId> <version>1.6.1</version> </dependency>

次に ViewResolver を設定します。ここでは SSP を使うようにしました。

@Configuration public class ScalateConfig { @Bean public ViewResolver scalateViewResolver() { ScalateViewResolver r = new ScalateViewResolver(); r.setPrefix("/WEB-INF/scalate/"); r.setSuffix(".ssp"); r.setContentType("text/html; charset=utf-8"); return r; } }

これで準備 OK。

テンプレートファイル

Scalate ではレイアウト機能がありますのでそれを使ってみます。

親レイアウトとなる basic.ssp を用意。

<%@ val title: String %> <%@ val body: String %> <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <link rel="stylesheet" href="../../../stylesheets/main.css"> <title>${title}</title> </head> <body> ${include("../layout/navibar.ssp")} <div class="container"> ${unescape(body)} </div> ${include("../layout/footer.ssp")} <script src="../../../javascripts/jquery-2.0.0.min.js"></script> ${unescape(script)} </body> </html>

コンテンツ側から basic.ssp を指定すると ${unescape(body)} のところに差し込まれます。

<%@ val wikiPage: net.physalis.javaviews.domain.model.WikiPage %> <% attributes("layout") = "/WEB-INF/scalate/layout/basic.ssp" %> <% attributes("title") = "Scalate" %> <article> <h1>${wikiPage.getTitle}</h1> </article>

デフォルト HTML エスケープ

Scalate では何も設定しなくてもデフォルトで HTML エスケープされます。

前回までに使っていたのと同じモデルを使って動作を検証してみます。

WikiPage wikiPage = new WikiPage( "<strong>Tokyo</strong>", new WikiText("<strong>Tokyo</strong> is the capital of Japan."));

まず title の出力です。

エスケープできていますね。 Java のクラスを参照する場合、プロパティ名ではなく ${wikiPage.getTitle} のように存在するメソッドを指定する必要があるのがちょっと微妙です。

続いて WikiPage の出力。

WikiPage#toString() の結果をエスケープできています。

今度は明示的にエスケープを回避してみます。${unescape(...)} を使うとエスケープなしで出力できます。

クラス定義によりエスケープをスキップする方法はわかりませんでした。

まとめ

Scalate は Java からも使え、Spring MVC 用のクラスが提供されていて簡単に組み込むことができます。レイアウト機能を標準装備、型安全で、SSP だけでなく Jade や Mustache などいろんなテンプレートが使えるなど魅力的な要素がたくさんありますね。

設定なしで HTML エスケープされ、${unescape(...)} によりエスケープなしで出力することができます。getXXX のようにプロパティ名ではなくメソッド名を使わないといけないのは微妙ですが許容範囲かな。

Java から Scala を呼び出すということで、別のバージョンの scala-compiler.jar を要求するライブラリがあったらどうしようとか、何か問題があった時のために Scala のコードを読めた方が安心とか、このへんが許容できるプロジェクトでかつ Scala じゃなくて Java を使わないといけないプロジェクト (どんなの?) なら使ってもおもしろいかも。

検証に使ったソースコードは github にあります

デフォルト HTML エスケープシリーズ。今回は FreeMarker。

デフォルトエスケープの設定

FreeMarker では <#escape> タグで囲った部分を自動でエスケープすることができます。こんな風にファイルの最初と最後にセットしてやればそのファイルではデフォルトでエスケープされます。

<#escape x as x?html> <!DOCTYPE html> <html> ... ${foo.bar} ... </html> </#escape>

いちいち <#escape> で囲むのは面倒ですので TemplateLoader でテンプレートをロードするときに自動でつけるようにします。SpringMVC と組み合わせる場合は以下のようになります。(完全なソースコードはこちら)

FreeMarkerConfigurer c = new FreeMarkerConfigurer(); c.setPreTemplateLoaders( new SpringTemplateLoader( new ServletContextResourceLoader(servletContext), "/WEB-INF/freemarker/") { @Override public Reader getReader(Object templateSource, String encoding) throws IOException { String s = CharStreams.toString( super.getReader(templateSource, encoding)); return new StringReader( "<#escape x as x?html>" + s + "#escape>"); } }); return c;

ちょっと無理矢理な気もしますがこれで <#escape> を付け忘れてしまう心配はありません。

動作検証

JSP, Velocity の時と同じモデルを使って動作を検証します。

WikiPage wikiPage = new WikiPage( "<strong>Tokyo</strong>", new WikiText("<strong>Tokyo</strong> is the capital of Japan."));

まず title の出力です。

エスケープできていますね。続いて WikiPage の出力。

WikiPage#toString() の結果をエスケープできています。

今度は明示的にエスケープを回避してみます。<#escape> 内で <#noescape> を使うとエスケープなしで出力できます。

JSP や Velocity のようにクラス定義によりエスケープをスキップする方法はわかりませんでした。

まとめ

<#escape> を自動的にファイルの前後に挿入することによりデフォルト HTML エスケープを実現できました。クラス定義でエスケープを回避できればさらによかったのですがエスケープ漏れはないので優秀ですね。

検証に使ったソースコードは github にあります

前回 は JSP でのデフォルト HTML エスケープを検証しました。今回は Velocity を見てみます。

デフォルトエスケープの設定

Velocity では ReferenceInsertionEventHandler を使ってデフォルトでの HTML エスケープを実現できます。このクラスは名前の通り参照がテンプレートに挿入される時にフックして値を操作することができます。

コード例です。完全なソースコードはこちらを参照してください。

public class MyRefrenceInsertionEventHandler implements ReferenceInsertionEventHandler { @Override public Object referenceInsert(String reference, Object value) { if (value == null) { return null; } else if (reference.endsWith("NoEscape") || reference.endsWith("NoEscape}")) { return value; } else if (value instanceof SafeHtml) { return ((SafeHtml) value).getSafeHtmlValue(); } else { return escape(value.toString()); } } }

ここでの処理は以下の通りです。

参照名が NoEscape で終わっていたらエスケープしない

値が SafeHtml を実装していたらエスケープしない

それ以外の場合はエスケープする

JSP の ELResolver が EL の一部を受け取るのと違って、ReferenceInsertionEventHandler では完全な参照名を受け取れるので String 以外をエスケープできないなんてことはありません。

動作検証

JSP の時と同じモデルを使って動作を検証します。

WikiPage wikiPage = new WikiPage( "<strong>Tokyo</strong>", new WikiText("<strong>Tokyo</strong> is the capital of Japan."));

まず title の出力です。

エスケープできていますね。続いて WikiPage の出力。

WikiPage#toString() の結果をエスケープできています。前回の JSP はエスケープできていませんでした。

今度は明示的にエスケープを回避してみます。

ReferenceInsertionEventHandler で書いたように NoEscape で終わる参照名の場合はエスケープしません。

こちらも SafeHtml を実装している場合はエスケープしません。

まとめ

ReferenceInsertionEventHandler を使ってデフォルトでの HTML エスケープ、参照名とクラス定義による明示的なエスケープの回避ができました。完璧ですね。

検証に使ったソースコードは github にあります

JSP で HTML エスケープするには <c:out> や fn:escapeXml を使うわけですが、いちいち書くの面倒だし付け忘れるもありがちです。付け忘れがないことを確認するにはコードを全部見たり、静的解析ツールを使ったり、サイトに対して XSS 検出ツールを使ったり、とても大変です。

そこで、デフォルトでエスケープする方法を考えてみます。具体的には次の機能を実現します。

デフォルトでエスケープする

<noescape> タグで囲った部分はエスケープしない

SafeHtml インターフェースを実装したクラスはエスケープしない

これらは ELResolver を使うと ある程度 実現できます。この後その方法と限界を見てゆきます。

ELResolver の実装

ELResolver では String のエスケープを行います。ソースコード全文は長いので こちら を参照してください。

下記コードにより ELResolver チェインにより解決した値が String の場合はエスケープします。SafeHtml の場合はエスケープしません。

Object value = context.getELResolver().getValue(context, base, property); if (value instanceof String) { return escape((String) value); } else if (value instanceof SafeHtml) { String html = ((SafeHtml) value).getSafeHtmlValue(); context.setPropertyResolved(true); return html; } else { return value; }

また <noescape> タグをサポートするために request に NO_ESCAPE_KEY 属性があると処理をスキップします。

Boolean noescape = (Boolean) jspContext.findAttribute(NO_ESCAPE_KEY); if ((noescape != null && noescape)) { return null; }

noescape タグのソースコードは下記ようなものです。noescape.tag

<%@ tag pageEncoding="utf-8" trimDirectiveWhitespaces="true" %> <% request.setAttribute(EscapeHtmlElResolver.NO_ESCAPE_KEY, true); %> <jsp:doBody/> <% request.removeAttribute(EscapeHtmlElResolver.NO_ESCAPE_KEY); %>

検証用モデル

続いて準備として検証に使うモデルを用意します。Wiki ページを表す WikiPage とそのページ本文である WikiText です。

public class WikiPage { public WikiPage(String title, WikiText wikiText) { this.title = title; this.wikiText = wikiText; } public String getTitle() { return title; } public WikiText getWikiText() { return wikiText; } @Override public String toString() { return "WikiPage(" + title + ", " + wikiText + ")"; } private final String title; private final WikiText wikiText; }

WikiPage は String 型の title プロパティと WikiText 型の wikiText プロパティを持ちます。ログ出力やデバッグ時に便利なように toString() も実装してあります。

public class WikiText implements SafeHtml { public WikiText(String value) { this.value = value; } public String getValue() { return value; } @Override public String getSafeHtmlValue() { eturn value; } private final String value; }

WikiText は <script> など危険なタグを取り除いた HTML を持ち、このままレンダリングすることが想定されています。インターフェース SafeHtml とそのメソッド getSafeHtmlValue() を実装することで表現しています。

public interface SafeHtml { String getSafeHtmlValue(); }

動作検証

プロパティに HTML タグを含む次のモデルを使って動作を検証します。

WikiPage wikiPage = new WikiPage( "<strong>Tokyo</strong>", new WikiText("<strong>Tokyo</strong> is the capital of Japan."));

まず title の出力。

デフォルトエスケープできた! でもこれには抜け道があって、String 以外のクラスのレンダリングではエスケープされません。

太字になっている部分は <strong> によるものです。WikiPage#toString() がエスケープなしで出力されていますね。HTML が含まれるクラスの toString を意図的に利用することは少ないと思いますがうっかりやってしまうかもしれません。toString を使っていないことの調査は大変そうです。

noescape タグでのエスケープスキップはちゃんと動きます。

WikiText は SafeHtml インターフェースを実装しているのでそのままでエスケープを回避できます。

noescape タグはあれば便利だけど、JSP ではなく Java コードで実現できる SafeHtml を使った方が、ビューの役割を限定できて良いと思います。自動テストも書きやすいしね。

まとめ

JSP では ELResolver を使ってある程度デフォルト HTML エスケープを実現できます。タグやクラス定義により明示的にエスケープしないことも可能です。ただし String 以外がレンダリングされるときはエスケープされない大きな抜け道があります。

自分にとってこれはちょっと許容できないなぁ...

検証に使ったソースコードは github にあります

こちらのサイトで動作を確認できます

grep -B <前の行数> とか -A <後ろの行数> とか -C <前後の行数> とか。

Flyway は Java で書かれたシンプルな DB マイグレーションフレームワーク。

クラスパスに /db/migration/V1__Create_book_table.sql などと V__.sql なファイルを置いておけば様々な方法で実行できる。maven プロジェクトだったら src/main/resources/db/migration/ で OK。

実行方法には API (プログラム)、Maven プラグイン、コマンドラインツール、Ant タスクがある。

運用方法としてはたとえば開発環境では Maven プラグインでマイグレーションして、本番環境ではデプロイプロセス内で DB コマンドを使って SQL ファイルを実行するのがちょうど良いと思った。

2013/4/18 に開催された 史上初☆MakeLeaps User Meetup に参加してきました。MakeLeaps を作っている方々、使っている方々と楽しく刺激的な時間を過せました。

去年はじめてフリーランスとして仕事をして請求書の書き方で悩んでいるときに MakeLeaps に出会い、フォームにちゃちゃっと入力して「郵送する」ボタンを押したらあとはお任せなのでだいぶ楽できてる。今年から復興特別所得税が始まりましたが自動で計算してくれるので特に悩むこともなかったです。

そうそう、MeetUp でみごと抽選を引き当ててマグカップいただきました。ありがとうございました。セイ君、だそうです (^^

logback の設定ファイル内で条件分岐 では設定ファイル内で環境ごとに分岐したけれど、差異が大きい場合はファイルをごっそり分けた方がよいでしょう。logback では ContextInitializer が設定ファイルの読み込みを行っています。これを設定ファイル名とともに明示的に呼ぶことで再設定できます。

ServletContextListener でシステムプロパティ app.env の値によって log-<app.env>.groovy を選択する例

import ch.qos.logback.classic.LoggerContext; import ch.qos.logback.classic.util.ContextInitializer; import ch.qos.logback.core.joran.spi.JoranException; import org.slf4j.LoggerFactory; import javax.servlet.ServletContextEvent; import javax.servlet.ServletContextListener; import javax.servlet.annotation.WebListener; import java.net.URL; @WebListener public class LogConfigListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent sce) { try { LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); context.reset(); new ContextInitializer(context).configureByResource(getConfigUrl()); } catch (JoranException e) { throw new RuntimeException(e); } } private URL getConfigUrl() { return Thread.currentThread().getContextClassLoader().getResource(getConfigFilename()); } private String getConfigFilename() { String env = System.getProperty("app.env"); if (env == null) { return "log.groovy"; } else { return "log-" + env + ".groovy"; } } @Override public void contextDestroyed(ServletContextEvent sce) { } }

環境に応じて設定をちょこっと変えたいなら logback.groovy で条件分岐してしまうのがお手軽。

システムプロパティに log.highlight=true があったときだけ logback の出力を色付けする の設定を有効にするならこんな感じ。

logback は ANSI エスケープシーケンスを使った色付き出力をサポートしています。 http://logback.qos.ch/manual/layouts.html#coloring

ファイルに出力するときはジャマだけど、開発中にコンソールを色付けするのは楽しいんじゃないだろうか。

logback.groovy を用意します。

import static ch.qos.logback.classic.Level.* import ch.qos.logback.core.ConsoleAppender import ch.qos.logback.classic.encoder.PatternLayoutEncoder appender("STDOUT", ConsoleAppender) { withJansi = true encoder(PatternLayoutEncoder) { pattern = "%white(%date{HH:mm:ss.SSS}) %highlight(%-5level) %cyan(%logger{15}) %highlight(%message) %n" } } root(DEBUG, [ "STDOUT" ])

mvn jetty:run してみると…

Jetty の起動が遅い!

Jetty は起動の速さが売りのひとつですが、構成によっては起動時に次のメッセージをログ出力してしばらく固まります。数秒から十数秒、ググったら 45 秒なんて例もありました。

No Transaction manager found - if your webapp requires one, please configure one

このとき Jetty は Servlet 3.0 のアノテーションのついたクラスを探したり ServletContainerInitializer の処理をしていて、WEB-INF/lib 以下の jar ファイル数、クラス数が多ければそれだけ時間がかかります。

解決方法

次の設定で解決します。

web.xml の metadata-complete

jetty の webInfIncludeJarPattern

特に後者の効果が大きいです。(前者は違いを体感できませんでしたが、一部の処理がスキップされるので少しは違いがあるはず)

web.xml の metadata-complete

構成によっては指定できないこともありますが、できるなら true にしてしまいましょう。

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0" metadata-complete="true"> </web-app>

jetty の webInfIncludeJarPattern

jetty-maven-plugin を使っている場合は pom.xml に webInfIncludeJarPattern を指定して必要最小限の jar だけ探索させます。 値は ServletContainerInitializer と @HandlesTypes で指定されたクラスを含んだ jar にマッチする正規表現です。ServletContainerInitializer を使わないのであればマッチしないような値を指定します。(空文字は全てにマッチします)

<webInfIncludeJarPattern>^WILL_NOT_MATCH$</webInfIncludeJarPattern>

たとえば Spring は web.xml なしで Spring コンテキストを設定するために SpringServletContainerInitializer を提供しています。この機能を使いつつ Jetty の起動を遅くしないためには webInfIncludeJarPattern を次のように指定します。

<webInfIncludeJarPattern>^spring-web.*\.jar$</webInfIncludeJarPattern>

jetty-maven-plugin の設定例

<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>8.1.9.v20130131</version> <configuration> <webApp> <webInfIncludeJarPattern>^spring-web.*\.jar$</webInfIncludeJarPattern> </webApp> <stopKey>stop</stopKey> <stopPort>8091</stopPort> <connectors> <connector implementation="org.eclipse.jetty.server.bio.SocketConnector"> <port>8080</port> </connector> </connectors> </configuration> </plugin>

環境

git 管理のシンプルなテキストファイルからバーンダウンチャートを作る CUI ツールを書きました。 https://github.com/akr4/burndown

超シンプルなテキストファイルにタスクを記録して git にコミットしておくだけなので、エンジニアには楽なんじゃないかな (だったらいいな)。

こんなテキストファイルとその履歴から、

残り タスク名 2 "ユーザーを登録する" 実装 3 "ログインする" 実装 2 "イベントを登録する" 実装 2 "参加者を登録する" 実装 1 "イベント一覧を見る" 実装 1 サーバーデプロイ 0.5 "ログアウトする" 実装

こんなバーンダウンチャートができます。

ここではテキストファイルの先頭列が残り日数です。カラムの位置やカラム区切り文字はカスタマイズできます。

残り日数以外は使いませんので他の列に何を書いても大丈夫。

作業したら残り日数を減らしたり増やしたり、タスクを追加して git にコミットします。だいたいお昼の 12:00 に近いコミットをその日の値として採用します。

使い方

ソースコード取ってきて

git clone https://github.com/akr4/burndown.git cd burndown

ビルドします。

sbt compile stage

そして実行。

/target/start -r ../burndown-sample burndown.tsv -e 2013-2-15 -f "\s"

Mac ユーザーの方は target/start の PROJECT_DIR を . に変更してください。(sbt-start-script plugin 0.7.0 のバグ)

PROJECT_DIR=.

実行すると最後に URL が表示されるのでブラウザで見るとチャートが表示されます。

./target/start でヘルプが表示されます。

Google Chart API

簡単な DSL で REST API のドキュメントを書ける。手軽にキレイなドキュメントが作れて便利でした。

こんな↓ DSL で作ったドキュメントがこちら。 http://docs.test159.apiary.io/

Store 一覧の取得 GET /stores < 200 { "stores": [ { "id": 1234, "name": "金のさら" }, { "id": 2345, "name": "ピザキャップ" } ] }

プレビュー見ながら書けるのでわかりやすい。公開したくない場合はプライベートに設定することもできる。コメントや API のテスト機能もあったりして、なかなか使えそう。

たいていの場合、入出力に使うデータ型を定義してドキュメントに記載すると思うんだけど、そういう機能はないので現状では別のドキュメントを用意する必要がある。でも json schema 使ったデータ型定義も検討されているみたいだし、期待できそう。 (http://support.apiary.io/forums/120125-general/suggestions/3283512-use-json-schema-to-describe-data-types)、