DATE : 2008/04/13 (Sun)
システム専用のディレクトリを使用するシステムを開発していると、ディレクトリの指定方法に迷うことがあります。例えば、Hibernate を用いて全文検索を行うことのできる Hibernate Search では、インデックスをディレクトリに格納するため、そのディレクトリをプロパティであらかじめ指定しておかなければなりません。
こういった環境に依存する設定があちこちの設定ファイルやプロパティに散らばっていると、管理が大変です。そこで、Maven Resources Plugin のフィルタリング機能が使えます。この機能の使い方は、次の通りです。
- resources ディレクトリ以下のファイル中の置換したい文字列を${...}に置き換える。
- プロジェクト設定ファイル（pom.xml）に置換するプロパティを指定する。
- プロジェクトをビルドする。
resources ディレクトリ以下のファイル中の置換したい文字列を${...}に置き換える
例えば、resources ディレクトリ中のファイルに次のような設定があったとします。
<property name="hibernate.search.default.indexBase" value="c:/index" />
ここで、value 属性の値はディレクトリへのパスになっています。今回は、この部分をフィルタリング機能で置き換えます。置き換えのために、value 属性の値を${indexBase}に書き換えます。
<property name="hibernate.search.default.indexBase" value="${indexBase}" />
プロジェクト設定ファイル（pom.xml）に置換するプロパティを指定する
続いて、プロジェクト設定ファイル（pom.xml）の中に次の内容を追加します。（「...」は省略を表します）
<project>
...
<properties>
<indexBase>c:/index</indexBase>
</properties>
...
</project>
つまり、project タグ直下に properties タグを書き、properties タグの直下に置き換え対象の文字列のタグを作ります。
プロジェクトをビルドする
以上で、フィルタリング機能を使う準備は終わりです。Maven Resources Plugin は、初期設定でビルドサイクルから自動的に呼び出されるため、プロジェクトをビルドするだけで、resources ディレクトリ以下の${...}で指定された文字列が自動的に置換されます。
参考文献
- Maven Resources Plugin - Filtering 本記事は、この記事のまとめのようなものです。
DATE : 2008/02/05 (Tue)
Java SE が6 Update 3 から Update 4にバージョンアップしていたので、PC の JDK を更新したところ、GlassFish が動作しなくなってしまいました。サーバの起動や終了を行う際に使用する asadmin コマンドを使っても、次のようなエラーメッセージが出て動作しません。
指定されたパスが見つかりません。
GlassFish のバージョンは v2 Update Release 1で、Windows Vista 上で動作させています。「指定したパスが見つかりません」ということで、環境変数まわりを調査してみましたが、おかしなところは見当たりません。そもそも、JDK のバージョンアップ前は正常に動いており、java コマンドへのパスや JAVA_HOME 環境変数も問題ありませんでした。
そこで GlassFish の設定ファイルを探し回ったところ、「<GlassFish のインストールフォルダ>\config\asenv.bat」の中に次の行が見つかりました。
set AS_JAVA=C:\Program Files\Java\jdk1.6.0_03\jre/..
バージョンアップ前の JDK のパスを指定しているので、非常に怪しいです。そこで、この部分を現在の JDK のパスに書き換えてみます。すると、正常に asadmin が動作し、GlassFish も正常に起動しました。
（；^ω^）asenv.bat は、GlassFish 用の環境変数を設定するバッチファイルです。GlassFish は、Java の実行環境のパスを AS_JAVA 環境変数で独自に管理しているところが今回ひっかかった点でした。Ant や Maven などは JAVA_HOME 環境変数で管理していたので、GlassFish もそうだと思い込んでしまったわけです。
DATE : 2007/12/24 (Mon)
Java の java.util.regex.Pattern を用いると、正規表現を使用することができます。
正規表現を使って空白を区別するには、定義済みの文字クラスである「\s」を使用します。ところが、「\s」では半角スペースやタブ文字などは定義されていますが、全角スペースは定義されていません。
そこで、\p{javaWhitespace} を使います。この \p{javaWhitespace} は、Character.isWhitespace() の判定を行う文字クラスです。この判定基準のうち、Unicode の空白文字に全角スペース（IDEOGRAPHIC SPACE）が含まれているので、この文字クラスで半角スペースに加えて全角スペースも識別できます。なお、判定基準には Unicode の空白文字のほか、行区切り文字やタブ文字なども含まれているため、「\s」の代替として使えます。
参考文献
DATE : 2007/11/28 (Wed)
ImageIO などで読み込んだ画像がインデックスカラーかどうかを判断するには、その画像のカラーモデルのインスタンスが java.awt.image.IndexColorModel かどうかを判断するだけで分かります。
例えば、java.awt.image.BufferedImage の画像 image がインデックスカラーかどうかを判断するには、次のようにします。（import 文などは省略しています）
if ( image.getColorModel() instanceof IndexColorModel ) {
// image はインデックスカラー
}
（；^ω^）ImageIO を使った場合、読み込んだ画像のカラーモデルが自動的に設定されるので非常に便利です。
DATE : 2007/06/14 (Thu)
理不尽な不具合が発生した場合は、一度、コンパイル済み JSP ファイルを消してみるのもいいかもしれません。
稼動しているウェブアプリケーションのバージョンを上げようと、サーバを止めて新しいバージョンのファイル類を配備したところ、トップページで特定のクラスが見つからないという例外が発生してしまいました。
このクラスは、ある JSR 仕様を実装したライブラリに含まれていたもので、新バージョンでは別のベンダーが実装したものに置き換えていました。これだけであれば、あからさまに理不尽なのでコンパイル済み JSP ファイルを消去していたのですが、不具合の原因を究明するのを難しくしていた要因がもう一つありました。旧バージョンで使用していたライブラリに依存するライブラリを新バージョンでも使用していたのです。元々、旧バージョンで使用していたのは、JSR 仕様を実装したライブラリとそれを拡張するためのライブラリとして組でよく紹介されるライブラリでした。ところが、JSR 仕様を実装した方の品質があまり良くないので、それだけ別ベンダーのものに取り替えたのです。
ともに JSR 仕様を実装したライブラリなので、両者のインタフェースは同じです。そのため、開発機上では普通に動作していました。ところが、公開用サーバに移動したところでエラーが発生したので戸惑ってしまったわけです（また、開発機上と公開用サーバではサーブレットコンテナも違っていました）。
実際には、初めに書いたように、コンパイル済み JSP ファイルを消去しただけで正しく動作してくれるようになりました。公開用サーバのサーブレットコンテナは、JSP ファイルに変化があると自動的に再コンパイルするような設定になっていたのですが、どうもうまく変化を検知してくれなかったようです。
というわけで、理不尽な不具合が発生した場合、JSP ファイルが再コンパイルされなかったという状況も考えたほうがよさそうです。
（；^ω^）コンパイル済み JSP ファイルを消去しても不具合が直らなかった場合は、地獄の始まりのようなものですが……。
