S2Buri第１回勉強会参加

Seasar

　やはり手順にしたがってデモを見ると、実際の開発への適用をイメージできて良かったです。今携わっているプロジェクトだと、一気にシステム全体を置き換えるというのは難しいので、導入は難しかなぁと思いましたが、テーブルピックアップなんかは便利に色々使えそうです。これまでは、ダウンロードはしたものの、どう動かして良いのかわからなかったのですが、イメージが出来たので早速試してみたいと思います。
　Tuigwaaのデモも評判通り衝撃的でした。これまでのシステム開発は何だったのだろうと思う位、あっという間にWebアプリができてしまいました。適用方法をうまく考えると、これまでは、「システム化した方が良いけど、なくても業務はできるから後回し」にしていたようなところを簡単に改善できるように思います。こちらも、動かしてみないと！
　最近こうしたイベントにもなかなか参加できずにいたのですが、参加して良かったです。

OracleAS 10gでerrorStyleClass属性が使えない？

Seasar

　こちらも、Tomcat4.1では特に問題なく動いていたプログラムですが、OracleAS 10gにデプロイしたところ、strutsタグのerrorStyleClass属性が使えないようで、エラーなのにそのフォームのclass属性がうまく指定されない現象が発生しました。
　マニュアルを調べたところ、タグ・ハンドラ再利用の実行時モデルの無効化という内容の記述があったので、試しにpageContext.setAttribute("oracle.jsp.tags.reuse", new Boolean(false));を追加したらビンゴ。上手く動きました。
　ということで、全JSPにこれをつけるのもあんまりなので、さらに調査したところ、global-web-application.xmlファイルやorion-web.xmlファイルでtags_reuse_defaultをnoneに設定できるとの記述があったので、とりあえずorion-web.xmlに記述したものの、うまくいかず。global-web-application.xmlに記述したらうまくいきました。
　それにしても、strutsタグがタグ・ハンドラ再利用に対応してないのかな。とにかく、今日はこの２つの問題解決で疲れました・・・。<参考URL>
http://otndnld.oracle.co.jp/document/products/as10g/1012/doc_v1/web.1012/B15632-01/taglibs.html#147600
http://otndnld.oracle.co.jp/document/products/as10g/1012/doc_v1/web.1012/B15632-01/getstart.html#462263

S2StrutsのPOJO Form利用時の仕様について −その２−

Seasar

　id:kanag さんのコメントをもとに、BindingUtil.javaを下記のように修正してPOJO Formとして扱えることを確認しました。ありがとうございました。

BindingUtil.javaファイルの変更

ActionFormUtil.setActualForm(container.getRequest(), value, mapping);
　　　　　　　　　↓
String scope = mapping.getScope();
if (Constants.REQUEST.equals(scope)) {
    container.getRequest().setAttribute(mapping.getAttribute(), value);
} else {
    HttpSession session = container.getRequest().getSession();
    session.setAttribute(mapping.getAttribute(), value);
}

S2StrutsのPOJO Form利用時の仕様について

Seasar

　S2StrutsでPOJO Formを利用した場合に、画面遷移のパターンによってHttpRequestに格納されるオブジェクトの型が異なるようです。

  • entry.jspにフォワード→EntryInitActionでEntryFormに値を格納
    • この場合、HttpRequestにはPOJO Formそのものが格納される。
  • entry.jspからPOST→EntryActionでEntryFormに値を格納→entry.jspにフォワード→EntryInitActionでEntryFormに値を格納
    • この場合、HttpRequestにはBeanValidatorFormに変換されたEntryFormが格納される。

　この仕様に違いにより、JSTLタグでFormを扱おうとするとentryFormそのものを扱うか、entryForm.instance(BeanValidatorFormからPOJO Formを取得)を扱うかを遷移パターンによって切り替える必要が出てきてしまいます。
　仕様が異なる理由は、データがPOSTされた場合はProcessPojoFormInterceptorにより、POJO FormがBeanValidatorFormに変換されますが、直接jspにフォーワードされた場合はPOJO Formそのものが扱われるためと思われます。

　この仕様を統一する対応としては、現在BindingUtilのexportPropertyメソッドでHttpRequestに格納されるオブジェクトがBeanValidatorFormだった場合には、BeanValidatorFormを格納していますが、下記のようにPOJO Formそのものを返すことで対応可能なようです。現在、BeanValidatorFormを格納している理由は何でしょうか？

BindingUtil.javaファイルの変更

if (BeanValidatorFormUtil.isBeanValidatorForm(container.getRequest(), propertyName)) {
    BeanValidatorForm beanValidatorForm =
      (BeanValidatorForm) BeanValidatorFormUtil.toBeanValidatorForm(
          container.getRequest(), propertyName, value);
    value = beanValidatorForm.getInstance();
}

JSTLのi18nタグ(fmt)を利用したら文字化け

Etc

　Tomcat4.1でJSTLのi18nタグのを利用したところ、タグで出力している−が文字化けするようになりました。色々調べたところ、下記のサイトにあるようにfmtタグを利用すると対応するLocaleに該当する文字エンコーディングを暗黙でServletResponseに設定してしまうようです。
　よって、JSP上はcontentType="text/html;charset=Windows-31J"と設定しているのに、戻ってきたHTTPヘッダを見ると、"Content-Type: text/html;charset=Shift_JIS"になってしまっています。
　Servlet 2.4仕様のコンテナでは、明示的な指定が暗黙的な指定よりも優先するので問題ないようですが、Tomcat4.1(Servlet 2.3)だと暗黙的な指定で上書きされてしまうようです。
　pattern指定でASCIIコードしか返す予定がないのに、こんなところに影響してしまうなんて・・・。どう対応するのが良いのかなぁ。


【参考サイト】
　http://four.sssg.org/documents/jajakarta/taglibs/topics/docs/i18n_topics.html#topic-1
　http://java.sun.com/developer/technicalArticles/Intl/MultilingualJSP/index_ja.html