Seasar Archive

Cubbyのアクションクラスにはバリデーションルールの定義時やアノテーションに文字列が登場します。文字列で指定しているのでリファクタリングする時に修正漏れなどがおきそうでちょっと怖いです。そこで、それらの文字列を定数にしてしまえば、少しだけリファクタリングしやすくなりそうです。また、IDE上での参照元・参照先への移動や使われているかどうかのチェックも簡単になります。

例えば、次のようなアクションクラスがあるとします。

@Path("hoge")
public class HogeAction extends AbstractAction {

    @Binding(bindingType = BindingType.NONE)
    protected ValidationRules processApplyValidation =
        new DefaultValidationRules() {
            @Override
            public void initialize() {
                add("token", new TokenValidator());
                add("name", new TokenValidator());
                add("comment", new TokenValidator());
            }
        };

    @RequestParameter
    public HogeParameterDto hogeParameterDto;

    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form("hogeParameterDto")
    @Validation(rules = "processApplyValidation", errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }

}

これを次のようにします。

import static org.example.test.entity.names.Names.*;

@Path("hoge")
public class HogeAction extends AbstractAction {

    private static final String processApplyValidationName
        = "processApplyValidation";
    @Binding(bindingType = BindingType.NONE)
    protected ValidationRules processApplyValidation =
        new DefaultValidationRules() {
            @Override
            public void initialize() {
                add(TOKEN, new TokenValidator());
                add(post().name().toString(), new TokenValidator());
                add(post().comment().toString(), new TokenValidator());
            }
        };

    private static final String hogeParameterDtoName = "hogeParameterDto";
    @RequestParameter
    public HogeParameterDto hogeParameterDto;

    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form(hogeParameterDtoName)
    @Validation(rules = processApplyValidationName, errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }

}

変更した箇所を説明します。

しばらく時間が空いてからCubbyを使ったWEBアプリケーションを書く時に、アクションメソッドに指定するアノテーションの順番どうだったかなっと考えるのでまとめます。アノテーションなので適当な順番に書いても問題なく動作しますが、処理の流れを考えて次の順番で指定しています。

1. URIを指定: @Path
2. HTTPメソッドを指定: @Accept
3. 同一URIへのPOST時などに実行するアクションメソッドを変える指定: @OnSubmit
4. リクエストパラメータのバインド先を指定: @Form
5. リクエストパラメータのバリデーションを指定: @Validation

@Path("hoge")
public class HogeAction extends AbstractAction {
    ...
    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form("hogeParameterDto")
    @Validation(rules = "processApplyValidation", errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }
    ...
}

• 参考: Cubby Project – アクション

Seasarプロジェクトでも利用しているJIRA のライセンスを去年の10月に自分用に購入しました。JIRAを開発しているAtlassian社が10ユーザまで利用できるGet Started for $10というライセンスを始めたので思わず買いました。JIRA 4.0になって、JIRA 3.x以前にあったエディションの違いが無くなり、$10でEnterpriseエディションが使えるというのは破格です。JIRA 3.xまではLDAPサポートにEnterprise以上が必要でとても買える金額では無かったため嬉しいです。また、このライセンスの購入費用は全額 Room to Read に寄付されるプログラムになっています。

日本円で購入したい場合は、Atlassian社のOfficial Atlassian Partnerである リックソフト株式会社 が1,050 円で販売されています。

• Bug Tracking, Issue Tracking & Project Management Software – JIRA (Atlassian社)
• アトラシアン(Atlassian)製品の価格と購入（オンライン販売） (リックソフト株式会社)

そんなわけで、だいぶ前置置きが長くなりましたが、自分用にJIRAの環境を作りました。購入当初JIRA 4.0には 新しく導入されたガジェットの仕組みがSSL環境で上手く動かない問題 があったので、使い始めたのはこの問題がJIRA側で解決した4.0.1からです。

ただ、まだ問題があって、Seasarプロジェクトで利用していた3.xのインストール手順でwarファイルを作成し、Tomcatにデプロイするとエラーがでて上手く起動しないのです。いろいろ試してみると自分で追加していたPluginを全部外すと起動しました。そんなことをつぶやいていたらリックソフトのohnukiさんがコンタクトをくださっていろいろやりとりした結果、原因が判明しました。

原因は、JIRA 4.0からOSGiを使用した新しいPlugin機構(Version 2)がサポートされ、JIRA 3.xの時とPluginの配置の仕方が変わっていたことでした。これに気付かず、JIRA 3.xの導入の仕方で入れていたので上手くPluginがロードされなかったようです。一応、互換性のため、古いPluginの配置方法(Version 1)も使えるようですが、Tomcat 5.5.28では動作するものの、Tomcat 6.0.20では動作せず、それでエラーが出ていました。

• 参考: Managing JIRA’s Plugins
  • Version 1: atlassian-jira/WEB-INF/lib/ 以下に配置
  • Version 2: jira.home/plugins/installed-plugins/ 以下に配置
    • jira.home はJIRA 4.0から導入されたホームディレクトリ指定

というわけで、無事やっとPluginも使えるようになりました。ohnukiさんありがとうございました！

Pluginが使えるようになったので、SeasarプロジェクトのJIRAも近日アップグレードのテストをし、アナウンスを出した後に現在の3.13.5から4.0.1に更新したいと思います。

以下、何かの参考までにVersion 1 + Tomcat 6.0.20で起動した時の例外全文を記載しておきます。

Seasar Conference 2009 Autumn お疲れ様でしたー。セッション資料は順次掲載されると思います。

コミットログから気になっていたCMSのメール機能(Ymirセッション)とDomaを廊下からこっそり見たり、ちょうどよく最後だけ見れたmobyletのデモでGoogle App Engineへデプロイして動かしてるのを見て楽しんでいました。Blogopolisは途中まで見たものの、途中でお片づけで出てしまったので資料が掲載された続きみたいと思います。

あっという間に日が過ぎて、明日は Seasar Conference 2009 Autumn です。

Flexいじりたいなって思っているのでS2Flex2関係のセッションが気になっています。でも、1コマ目はこうげきりょくが2 あがったらしいYmirも気になります。

Seasar Conference 2009 Autumnのセッション情報 が公開されました！

3月9月14日12日(土)に Seasar Conference 2009 Autumn が開催されます。セッション情報はまだないですが奮ってご参加ください。

開催日: 2009年 9月 12日(土)
会場: 法政大学市ケ谷キャンパス 外濠校舎3F
主催: 特定非営利活動法人Seasarファウンデーション
後援: 法政大学情報科学部
参加費用: 無料

1.5.x系か1.6.x系にあげることも考えましたが今回はとりあえずパッチで済ませました。パッチは以下のどっちでもOK。1箇所だけ中身違う箇所があるけどやってることは一緒でした。

• [RHSA-2009:1203-01] Important: subversion security update のSRPMの中の subversion-1.4.2-CVE-2009-2411.patch
• Patch to 1.4.x branch for CVE-2009-2411 の添付ファイルのパッチ

Atlassianのサポートの方から64-bit JVMは推奨していないと教えていただき、32-bitに変えてみたところ、多少重い時は相変わらずあるものの全くアクセス不能になることはなくなりました。

ポインタとして示していただいたFishEyeのSystem Requirements にも下記のように急激にメモリを消費するってちゃんと明記されていました。

We strongly recommend the use of a 32-bit JDK/JRE rather than a 64-bit JDK/JRE. 64-bit JDK/JREs will consume the available RAM more rapidly, and this may result in poor performance.

他のインストール方法や管理、パフォーマンスチューニングのドキュメントは読んでたけど、肝心のSystem Requirementsはスルーしてました。。

32-bit JVMに変えたのでVMのパラメータも変更しました。

FISHEYE_OPTS="-Xms512m -Xmx2048m -XX:NewSize=256m -XX:MaxNewSize=256m \
-XX:PermSize=128m -XX:MaxPermSize=128m"

• FishEyeが重い
• FishEyeが重い (2)

どうやらSVNへのアクセス中にSVNKitの例外が発生すると、その後ひどいことになるらしい。

FishEyeのソースは見れないのでAtlassianにサポートをお願いしてみました。

2009-08-04追記: とりあえず解決しました。

• FishEyeが重い
• FishEyeが重い (2)
• FishEyeが重い (とりあえず解決)