programの最近のブログ記事

Taxonomy of class loader problems with Jakarta Commons Logging

tomcatで開発をしている時に、コンテキストの更新を何度も行うとOutOfMemoryErrorが発生することがあるので、いろいろ調べていたところ、このページを見つけました。
JCLの、ClassLoaderが絡んだ場合の挙動についてサンプル付きで詳しく説明してあります。

回り道日記 - WebappClassLoader が解放されない件の原因１にて、

1. TOMCAT_HOME/bin/commons-logging-api.jar を commons-logging-1.0.4.jar で置きかえる (同名にして上書き)
2. TOMCAT_HOME/common/endorsed に log4j.jar を置く

とのことでしたが、これの理由というわけでした。

ただ、今回紹介されている方法はちょっと違いまして、

For Tomcat 5.0.27 and later, Make sure you are using JCL version 1.0.4 or later. Tomcat version 5.0.x ships with an outdated version of JCL.

1. Leave the file TOMCAT_HOME/bin/commons-logging-api.jar as is. In particular, do not remove it.
2. Place the files commons-logging.jar and log4j.jar in the directory TOMCAT_HOME/commons/lib/.
3. Do not include any other copies of commons-logging.jar and log4j.jar in your web-applications' WEB-INF/lib/ directory.
4. Do not set the system properties org.apache.commons.logging.LogFactory or org.apache.commons.logging.Log.

というわけで、common/libを利用するというもの。
でも、この方法だと、コンテキスト別のlog4jの設定が効かないのです。。。

はて、、、

Javaとか - 境界ワイルドカード

Java5のジェネリクスにある、Foo<? extends Baa>みたいな記述は、いつ使うんだろうとずっと思っていたけど、こんな風に使うんですね。

詳細はワイルドカードを見てください。

Java のクラスアンロード (Class Unloading)

クラスローディングのあたりをそろそろ勉強しておこうかと。
実際問題、これがないと困ることが出てきてしまいました。

記事としてはちょっと前のものになりますが、分かりやすく解説してあるので、大変参考になります。

TL - Perlフレームワーク

うちの会社で使っているPerlライブラリの後継フレームワークが公開されてます。
会社で使っていたライブラリの問題点を改善し、より洗練されたフレームワークになってます。
これまで社内でしか使えなかったライブラリ群がオープンになったことで、普段も気軽に使えて便利になるです。

まだ開発バージョンという位置づけですが、大部分は固まっており、もう少し様子を見たら正式版。
このフレームワークの仕様策定には僕も参画しており、一部僕が構築した部分も含まれているので、期待度も大。

よろしければ使ってみてください。
フィードバックもお気軽に～～♪

自宅サーバーや会社のいろいろも一段落な感じなので、しばらく放置していたtrf、JaBot両プロジェクトを再開しましょ。

trfの残タスク
・ リーダーをSeasar2にて再実装
・ 表示の機能拡充
・ RSSの再構成配信
・ ユーザー管理
などなど

JaBotの残タスク
・ チャンネルごとのイベントリスナ管理
・ ログの保存、全文検索
などなど

相変わらず、の～んびりいきます。

久しぶりに自宅サーバーのメンテをしてみました。

Apacheを、2.2.0だったものを2.2.2にアップデート。
また、これまでsvnservで管理していたSubversionを、Apache2＆DAV svnを利用するように変更。
通信を暗号化するために、SSL配下とする。

以上の３点がメンテ内容です。

ApacheのアップデートとSSLのセットアップはすぐにできたんですが、Subversionが苦戦しました。
Apache2.2系と連携する場合には、普通に

# ./configure --with-apxs=/usr/local/apache2/bin/apxs
# make
# make install

ではだめだったらしく、うまくいかずにいろいろと探し回っていて、ようやく行き着いたのがふたつの川うるおう日記(2005-12-04)というページ。

# ./configure --with-apxs=/usr/local/apache2/bin/apxs --with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2 --with-ssl

と変更することで、ようやく実現できました。

うちの自宅サーバーで動いてるフィードクローラのクロールノウハウと、Luceneの機能を使って簡易検索エンジンを作ってます。

とりあえずバージョン0.1ということで、会社のvmwareを拝借して某巨大ショッピングサイトをクロール中。
ここ数日で25000ページほどを巡回して6000ページほどをインデックス化しています。
油断するといろんな不具合が発生してしまうので、なかなか全ページのクロール＆インデックス化はまだまだ難しいですね。

こんなんやるとGoogleの偉大さが分かります。

ueshin@happy-camper.st: なぜかIRCボット

にてお知らせしました、IRCボット「JaBot」のバージョン0.1をリリースしました。
といっても、会社で利用しているIRCの片隅でこっそり常駐してるだけですが。

でも、キーワードに反応して、フィードを取得してきて貼り付けてくれたりとかの機能がついてます。
今は入室中の全チャンネルでキーワードに反応して、微妙に不評を買っているので、チャンネルごとに設定できるように修正を。
また、入室中のチャンネルログを取っていって、Luceneを使って全文検索ができるようにしたりする予定。
その前にリファクタリングを～とか。

ちゃんとtrac使って管理すべきか。
ふむ。

Apache Lucene入門

全文検索をば調査中。
Javaで全文検索といえばLucene。

いろいろ調べてたら今度書籍が出版されるみたいなので、買ってみようかな。

それはそうと、関連プロダクトのNutchも久々に調べていたところ、こんなページを発見。
その昔Nutchについて調べたのをwikiにまとめていたんですが、その文章がそのままコピペってある。。。
wikiテキストをそのまま貼り付けてあるので意味が通じない部分があったり、文章だけでなく、和訳に不備があったときの連絡先が僕のメアドだったりしてるし。。。

ま～、気にしない気にしない。。。

気がつけばゴールデンウィークも終わったなぁ。
というわけで、うちの自宅サーバーで動いてるRSSクローラがバージョンアップしました。

これまで自作ライブラリで稼動していたフィードのパーサを、ROMEというライブラリに変更。
これによって、いろんなバージョンのフィードを読めるようになりました。

さっそくこれまで登録できなかったフィードをいくつか登録。
バージョンを気にしないでいいのはべりぎゅーです。

なぜか社内でIRCボット作成が流行っています。

便乗して、ネットにあったソースを元に僕もやってみることにしました。
思えばネットプログラムはあまりやったことないのでいい勉強になりそう。

こちらも暇な時間にちょっとずつやっていきましょ。

Maven - Welcome to Maven

便利ですねぇ。
思わずこれまでのプロジェクトをいくつか（といってもいくつかしかないけど）Maven管理に変更してしまいました。

コンパイルやパッケージングはもちろん、プロジェクトサイトの自動生成やチェックスタイルもできる。
いろいろ設定もあるだろうから、これからこちらの方も調べていきましょ。

Teeda

試してみました。

●MyFacesと違って、日本語が&xxxx;形式にならなくて良い！
MyFacesだと日本語部分が &xxxx;（文字コードによる実体参照）に自動変換される（のは僕だけ？）のが嫌だな～と思っていたけど、Teedaだと普通に日本語として扱ってくれます。
MyFacesはcommons-lang.StringEscapeUtilsを使ってるから？
Velocityのescツールも、内部的にStringEscapeUtilsを呼び出しちゃうので、日本語が&xxxx;になってしまうのがびみょー。
文字化けを防ぐ意味では確実なんだけど、構築時の動作確認などがしにくく、日本語として扱ってくれるTeedaの方がうれしいです。
（この辺、JSFのリファレンス実装はどうなんだろ？）

●エスケープ処理が不十分
テキストエリアで、入力エラーなどがあって再表示する際に、エスケープ処理がなされていません。
ので、</textarea> とか書くと、その時点でテキストエリアではなくなるので、XSSなどのセキュリティホールにつながります。

●カスタムバリデータが使えない？
MyFacesより、tomahawkのバリデータを利用しようと思ったんだけど、うまく動かないようです。
一回目の画面表示の際の初期化処理は走りますが、いざ入力チェックを、という時にはnullになってしまいます。
これは、どこかのdiconファイルに設定を書いておくべきところなのかもしれませんが、設定を書かなければ動かないということであれば、有用性が下がることになりそうです。
（これに関しては回避できるのかもしれませんが、まだやり方がわかんないです。）

他にも、MyFacesと挙動が違う部分があるので、困惑することがあります。

とりいそぎ、こんな感じです。
個人的にはJSFを使っていきたいと思っているので、是非ともいいプロダクトに仕上がって欲しいです。
陰ながら応援させていただきます！

Teeda

Seasarファウンデーションのプロダクトだし～。
ちょっと試しに使ってみようかな。
でもまだベータ版だしドキュメントも少ないようですね。

見た感じ普通にJSFっぽく作るみたいですが、これとS2JSFの組み合わせはいけるのでしょうか。
S2JSFのテンプレート機能はわかりやすいので採用したいです。
組み合わせられるのであれば是非。

VelocityViewServletにはキャッシュ機能がついてますが、こちらがうまく動作しないようです。

●WebappLoader.templatePaths に保存されているキャッシュを取り出せない(?)。
VelocityTools1.2より、WebappLoader内にテンプレートのパス情報をキャッシュしますが、こちらへの登録時と取り出し時のパスの指定が違うため、保存されているキャッシュを取り出せないようです。

取り出しの際には、request.getServletPath()+request.getPathInfo()の形式をキーとして取り出す（取り出したパスは、"/"で始まる）ため、キャッシュへの登録キーも "/" で始まる必要があります。

これを回避するには、WebappLader.java : 151行目

-    templatePaths.put(name, paths[i]);
+    templatePaths.put("/" + name, paths[i]);

と変更します（動作未確認）。

●テンプレートに更新があり、キャッシュの再読み込みをする際に、マルチスレッド対応ができていない(?)。
テンプレートの更新を検知した際に、Template#process() ～ Template#merge(Context context, Writer writer)の処理が多重起動した場合、最後のスレッド以外のmerge()が例外を投げます。

VelocityEngineは１つのインスタンスとなるので、process()の始め、

    data = null;

の部分が、他のスレッドにも影響を与え、Template.java : 242行目のif分にてテンプレートが正常に処理されていないものとみなされ、

Template.merge() failure. The document is null, most likely due to parsing error.

との例外が投げられます。
きわどいタイミングですが、JMeterなどで同時アクセスのテストをすると、結構な頻度で例外を投げます。
大量のアクセスのあるサイトなどでは例外が頻発する可能性があります。
（上記のキャッシュ問題が回避されれば、例外出現の可能性はテンプレート更新時の直後の瞬間に限られるはずですが。）

これを回避するには、Template.java : 87行目

-    data = null;

とすればいいと思われます（が、影響範囲の特定はできていません）。

また、
velocity.propertiesにおいて、

webapp.resource.loader.cache = false

キャッシュをオフにする。
ただし、テンプレートを毎回読み込むので、負荷がかかる。

もしくは、

webapp.resource.loader.modificationCheckInterval = 0

テンプレートキャッシュの更新を行わない。
ただし、テンプレートの更新を行うには、VelocityViewServletの再起動をする必要がある。

の指定をすることで回避することができます。

こちらのいずれかは、上記であげたキャッシュの問題も同時に回避できるので、開発時には例外に目をつぶり、結合テスト～本番稼動時にこちらのいずれかの処置をとる、でも良いかもしれません。
どちらの処置をとるかは、運用による（テンプレートを更新するならキャッシュを無効に、しないなら更新を無効に）ので、案件によってそれぞれ検討することになります。

テストケースを書き始めまして、本格的にリファクタリングを開始しました。

パッケージングにむけての準備も開始。
とりいそぎSeasarプロダクトの作法に合わせて、Tigerアノテーションを分離して、定数アノテーションの実装。
もいっこのBackport175アノテーションがよくわかんないので、後回しにすることに。

あとはがしがしテストケース書いてテストしつつ、リファクタリングを進めていきます。
まだまだ微妙な実装や既知の不具合が多いので、少しずつつぶしていきましょう。

先日より取り組んでいた、Servletベースのフレームワークの β版 が完成しました。
DIコンテナに思いっきり依存しているので、現状ではSeasar2を使う必要があります。
ただし、SpringFramework上で動作させるのもそんなに難しくなさそう。

作成するServletはPOJOで作成できて、かつ、充分な記述力のなかった url-pattern を、正規表現で指定できるようになりました。
このあたりは S2Struts や S2JSF の実装を参考にしているので、S2プロダクト群に慣れている人にはとっつきやすいと思います。

ビューへのフォワードなどの設定は Tigerアノテーションを使うようにしたので、ソース書きながらサクサク設定も組み込んでいけます。
このアノテーション作法はS2Strutsのほぼパクりになってますが。。。ｗ

HogeServlet.java

@Servlet( urlPattern = "/hoge\\.html", parameter = "Command" )
public interface HogeServlet {
    
    @ServletForward( path = "/WEB-INF/jsp/hoge.jsp" )
    public String HOGE = "hoge";
    
    @ServletForward( path = "hoge.html", redirect = true )
    public String POSTED = "posted";
    
    public String doGet();
    
    public String doPostMessage();
    
}

HogeServletImpl.java

public class HogeServletImpl implements HogeServlet {
    
    private HogeService hogeService;
    
    public int getHogeService() {
        return hogeService;
    }
    
    public void setHogeService(HogeService hogeService) {
        this.hogeService = hogeService;
    }
    
    private HogeDto hogeDto;
    
    public int getHogeDto() {
        return hogeDto;
    }
    
    public void setHogeDto(HogeDto hogeDto) {
        this.hogeDto = hogeDto;
    }
    
    private List<Message> messages;
    
    public String getMessages() {
        return messages;
    }
    
    public String doGet() {
        messages = hogeService.getMessages();
        return HogeServlet.HOGE;
    }
    
    public String doPostMessage() {
        hogeService.doSomething();
        return HogeServlet.POSTED;
    }
    
}

こんな感じですね。

ServiceはDIコンテナからのインジェクション、Dtoはフォームデータをセット、messagesはこのサーブレットでの処理が終わったら自動的にrequestの属性として抽出される（JSFちっく）という仕様です。
また、@Servletアノテーションで指定してある parameter値 の名前を持つフォームを見て、実行するメソッドが変わります。
上記の例では、doPostMessageを実行するには、Command=messageをPOSTする、といった感じです。
指定がなければ、doGet()かdoPost()が実行されることになります。

また、ご覧の通り完全なPOJOなので、テストも容易に実行できることになります。

まだβ版なのでこれからリファクタリングして、もう少し盛り込みたい機能があるのでそちらも実装、納得がいくレベルになったらリリースしようと思います。

Servletベースのフレームワーク構築開始。
といっても単純なコントローラ部のみで、ビューには関与しない予定。

Servletベースなので、組み合わせ自由。
VelocityとかMayaaとかを使ってください。

とりあえずServlet自体をDIコンテナに格納して、インジェクトしながらフォーム情報をDTOから取れるように。
この辺、最近のフレームワークの流行ですな。

Actionの代わりにServlet使ってるので、処理をビューに渡すには今のところRequestDispatcherを使うしかなくて、ということはrequestもresponseも引き継ぐ必要あり、か。
代わりといっては何ですが、指定のパラメータ値から呼び出すメソッドを変えるとか？
GETとPOSTの処理の違いを残したいので、

    doGetCommand(request, response)
    doPostCommand(request, response)

みたいな感じにするか。

そんな感じで続報をお待ちください。

一旦ServletでのS2ベース・フレームワーク構築に着手してみることに。
どれもこれも便利なフレームワークなんだけど、痒いところに手が届かない感じがしたから。

そんなに凝ってなくていいんです。
ちょっとした機能が欲しいんです。

JSF関連本を買ってみました。

S2JSFなら、いろんなコンポーネントをお手軽に組み込めるかも？と思ったので。
デザインは普通のHTMLを維持できそうだし。
とりあえずJSFの基本をお勉強してみて、よさげだったら採用するかも。

Strutsとちがって、入力チェックがビュー側にお手軽に記述できるし、アクションの記述もStrutsより楽チン。
デフォルトのValidatorが少ないのが難点だけど、カスタム作るのはそんなに難しくなさそう。
カスタムコンポーネントはもちろん、Validatorだけのライブラリ作って公開してみるのも良いかもね。

それにしても、情報量が少なく感じるのは使えないから？それともほんとにまだ情報がないだけ？