メランジ雑記帳

tomcatを使ってかなり年月がたつが、ログの管理がもう少しどうにかならないかと思うことがたびたびあった。
そこで、ここで公開します。
tomcatのディレクトリ/bin/catalina.shの実際にtomcatをstartで走らせるところで、以下のようにします。

elif [ "$1" = "start" ] ; then
　touch “$CATALINA_BASE”/logs/catalina.out
if [ "$1" = "-security" ] ; then
echo “Using Security Manager”
shift
(“$_RUNJAVA” $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs=”$JAVA_ENDORSED_DIRS” -classpath “$CLASSPATH” \
-Djava.security.manager \
-Djava.security.policy==”$CATALINA_BASE”/conf/catalina.policy \
-Dcatalina.base=”$CATALINA_BASE” \
-Dcatalina.home=”$CATALINA_HOME” \
-Djava.io.tmpdir=”$CATALINA_TMPDIR” \
org.apache.catalina.startup.Bootstrap “$@” start \
2>&1 | /usr/sbin/rotatelogs “$CATALINA_BASE”/logs/catalina.out.%Y%m%d 86400 540 > /dev/null 2>&1 ) &
　　 if [ ! -z "$CATALINA_PID" ]; then
echo $! > $CATALINA_PID
fi
　　　 else
(“$_RUNJAVA” $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs=”$JAVA_ENDORSED_DIRS” -classpath “$CLASSPATH” \
-Dcatalina.base=”$CATALINA_BASE” \
-Dcatalina.home=”$CATALINA_HOME” \
-Djava.io.tmpdir=”$CATALINA_TMPDIR” \
org.apache.catalina.startup.Bootstrap “$@” start \
2>& 1 | /usr/sbin/rotatelogs $CATALINA_BASE”/logs/catalina.out.%Y%m%d 86400 540 >/dev/null 2>&1) &

if [ ! -z "$CATALINA_PID" ]; then
echo $! > $CATALINA_PID
fi
fi

（編集後記：startup.sh secuirtyではなく、startup.shだけの場合もあるので、elseの場合も同様なコマンドを追加した）

このようにこのプロセスでパイプでファイルを拾い、ファイル名を日付でつけていくほ方法が単純でいいのである。なぜならログを書き出す側は全くどこに書き出しているかを意識しなくていいのであって、パイプでつないだプログラムにお任せしてしまえばいい。反対に、外部の別のプログラム（crontab)
で無理やりファイル名を変更する部分は問題がないだろうが、catalina.outというファイル名が12月31日を越えたあたりで12月31日のファイルという名前になって、新年を迎えるが、新年のファイルを気ままに作成しても、書き込み方法が、

1. Appendでファイルを開く、
2. 書く
3. ファイルを閉じる

という風になっていれば問題は小さいが（(1.でファイルを開きなおしているので、ファイルが新しく他人によって作成されても問題ない）、これでは効率がかなり悪い。

ということで、javaの場合はファイルは開いたままで単純に書くのが効率がよいので、ファイルが開かれたまま書きつづける。どこに？
ファイルが指し示すi -nodeは12月31日という名前にリネームされたファイルであるので、そこに書き続けることになる。そこで、catalina.outというカレントファイル（現在大きさがゼロ）に書かせるには、tomcatにファイルをもう一度開き直すように言わねばならない。しかし、そのような仕掛けはない。

別のシステムとしてsyslogインタフェースでログを書く場合があるが、これもログを書き込む側と通信で(UDP)接続しているという意味では上記のパイプと似た手法である。

また、同一のtomcat内でいくつかのアプリケーションで共通のログファイルを使って、log4jのサイズや日付などでファイル名の切り替えを行う処理をよかれと思ってしていると別のスレッドと内部でファイルの競合が起きて、行が交じり合ってかついろいろな日付の行がめちゃくちゃになって、という事態に遭遇する。また外部プログラムとの競合も起きる。できるプログラマーに限ってそういう目にあったりする。

もっと問題なのは、ログの設定を何度も至るところで行っていると、ファイル等がどうなるかは、神のみぞ知るという漢字になる。

tomcat6になって、libがひとつだけになって大変うれしい。またローダーの仕様もすっきりしたようだ。むかしはこのディレクトリなるものは、commonやsharedやserverやいろいろあって、私はそれに対しては大変批判的であった。ユーザのCLASSPATHを優先するとかあたり前の決断をよくしてくれた！！実はわかったふりをしている人間もよくわかっていなくて苦労していたようだ。その極めつけはcommons loggingであった。その著者もざんげをしたりしていたが、ともかくcommons loggingも禁止の方向ということで大変めでたい。わかんない！と言うところから理解が始まるのでは？盲目的な洋物万歳主義は権威主義に依存することになり、広く自由で理性的な思考を抑圧することになるので避けたい。

年末にインターネットでEE関係の記事を探していたら、三菱UFJは再起動しないで、ソフトの修正ができるようなものを求めていたというような記事を読んだ。

弊社でも、テストモードでは面倒なので、ant でwarファイルをコピーするだけで再起動なしで便利！というような使い方をしていたので、紹介する。

（あとにつづく）

tomcat 5では、

<Host name=”mel1″ appBase=”webapps”
autoDeploy=”true” deployXML=”true” liveDeploy=”true”
xmlValidation=”true”
unpackWARs=”false” debug=”0″ >

とし、かつContext用のXMLファイルを

~/tomcat/conf/Catalina/localhost/

に（上記のホストでlocalhostとしているから最後がlocalhostになるのだが）、

zip.xmlという名前で

<Context path=”/zip” reloadable=”true” docBase=”/home/hitoh/tomcat/webapps/zip” debug=”1″/>

というふうな感じで書いておくと、ant jarしたら即座にそれが反映されるようになる。これをしないとまったく再ロードしないようだった。

ant jarでは、~/tomcat/webapps/zip/WEB-INF/libにzip.jarをコピーしている。zip.jarについては、「郵便番号で住所を探すajax」という投稿で利用しているjarである。

このコンテクストには普通はdbcp（Database connection pool関係やデータソースを定義するところである）

tomcat 6での同様だった。

ログをみると、

2010-01-15 17:15:43,661 <INFO > (http-8080-1) [GetAddress.java:26]- try to make ZIPFind … with zip7=2540043
2010-01-15 17:15:43,663 <INFO > (http-8080-1) [GetAddress.java:28]- made ZIPFind instance
2010-01-15 17:15:43,705 <DEBUG> (http-8080-1) [ZIPFind.java:37]- connected ..
2010-01-15 17:15:43,712 <DEBUG> (http-8080-1) [ZIPFind.java:39]- sql is select ken, city, cho from zip where zip7=’2540043′
2010-01-15 17:15:43,753 <INFO > (http-8080-1) [ZIPFind.java:47]- ken = 神奈川県, city=平塚市, cho = 紅谷町
2010/01/15 17:17:16 org.apache.catalina.core.StandardContext reload
情報: このコンテキストの再ロードを開始しました
2010-01-15 17:17:26,750 <INFO > (http-8080-1) [GetAddress.java:26]- try to make ZIPFind(zip7=2540042)
2010-01-15 17:17:26,753 <INFO > (http-8080-1) [GetAddress.java:28]- made ZIPFind instance
2010-01-15 17:17:26,756 <DEBUG> (http-8080-1) [ZIPFind.java:37]- connected ..
2010-01-15 17:17:26,757 <DEBUG> (http-8080-1) [ZIPFind.java:39]- sql is select ken, city, cho from zip where zip7=’2540042′
2010-01-15 17:17:26,802 <INFO > (http-8080-1) [ZIPFind.java:47]- ken = 神奈川県, city=平塚市, cho = 明石町

というふうに、かってに再ロードしたといっている。try to make ZIPFind(zip7=2540042)に変更されているのであたらしいzip.jarが反映されている。

しかーし、これには欠点があって、少し遅くなるらしい。