ブラウザチェック用ツール

先月、作業用パソコンが変わりまして、OSがwindows7になりました
IEブラウザチェック用に、いままで　Multiple IE　を利用していたが、そいつXPしか動かない。

自分のwindows7がhome premiumなので、
XPモードを利用するにはXPのライセンスが必要、
いろいろ面倒くさくて、別のチェック用ツールを探しました。

そして「IETester」と出会いました
http://www.my-debugbar.com/wiki/IETester/HomePage
使ってみたら、問題なさそうで、よかった～

また、
http://spoon.net/browsers/
も使ってみました。
IE6の場合、たまに画面を開いた瞬間に落ちるケースもありますが、
それ以外はFFなど多数対応できるので
バックアップとして利用するつもりです。
プラグインのインストールが必要で、
http://www.hislab.net/blog/tools/spoon-browser-sandbox.html
には利用方法の説明があります。

URLリライトはjsessionidの対応を忘れないように

J2EEの仕様により、JSPの画面に貼り付くリンクが
生成方法により画面に表示されたら、
そのリンクのURLの末尾に";jsessionid=XXXXX"のようなものがつけられてしまうことがあります。
通常その情報がcookieにより送信するけれども、
ブラウザが閉じたまま、いきなりURLを開いた場合には
cookie対応されているかどうかの判断ができないようで、
そのような情報がURLに付加されます。

URLリライトを書く済に、
その内容の有無に関わらず正しくリライトできるように心がけないと、
画面の遷移がうまくできなくなったり、
予想外な画面に遷移してしまいます。

imageボタンのform二重送信に要注意

WEBアプリの画面デザインにはimageボタン(<input type="image" ...>)がよく利用されます。
仕様によって、onclick属性にjsの関数を記述して
その関数からform.submit()を呼び出して送信することもよくありますが、
imageボタン自身がformの送信も起こせますので、
ブラウザによってformの二重送信になってしまいます。
Firefoxでは特に問題ないですけど、
IEの場合には、容赦なく二重に送信してしまう。
解決方法としては

<a ... onclick="..." ><img src="..."></a>

のようにすることもいけますが、

<input type="image" ... onclick="xxx();return false;">

のようにimageボタンのonclickの最後に「return false;」
を付加する方法は一番シンプルを思います。

自動shellスクリプトでtomcat・apacheを起動する時にちゃんとチェックしましょう

定時にtomcatを再起動する要件があるシステムの保守をやっていますが、
shellスクリプトによりtomcatを再起動した後、
たまにWEBアプリケーションの動きがおかしくなって
一部の機能が働かない場合があります。
その障害が１年以上も続いてきて、
この間、根本的な原因がわかったようで、
メモしておきます。

【経緯】
WEBアプリケーションの実装にもよりますが、
今回のシステムにはWEBアプリAとBがあり
Aが別会社が作ったもので、
なんと、最初のアクセスで初期化処理を行うようです。
たまたま最初にアクセスが来たタイミングに、
そのアプリが完全にロードが終わっていない場合もあり、
その後、初期化処理がうまう実施できなくて、
起動後もずっと正常に動かなくなってしまいます。

自動再起動shellの処理は、以下の流れで処理しています。
①apache停止→一定の時間をsleep→チェック（リトライあり）
②tomcat停止→一定の時間をsleep→チェック（リトライあり）
③(何かしらの処理)
④tomcat起動→一定の時間をsleep→チェック（リトライあり）
⑤apache起動→一定の時間をsleep→チェック（リトライあり）

【問題】
④のチェックがtomcatのプロセスが存在するかどうかしか行っていないため
通常、起動コマンドを実行した直後が、tomcatのプロセスができたので、
そのチェックが実質的には意味ないのです。
tomcatの起動時間が「一定の時間をsleep」の時間より長い場合に、
結局tomcatが完全に起動できないまま、apacheが起動され、
そのうちWEBからのアクセスが飛んできたら
障害が発生するリスクが生み出したわけです。

【解決】
解決方法自体がそんなに難しくなくて、
WEBアプリに生存チェック用jspを用意して
tomcatのプロセスチェックがOKでたら、
さらにWEBアプリの生存チェックまでちゃんと行えば
今回の問題が解決できます。