→Java関連
→Java関連Tips
→Webアプリ開発
→Webサーバ
→JSF(JavaServer Faces)関連
→JSP関連
→Struts関連
→SAStruts関連
→JBoss Seam関連
一般記事 †
- WACsについて 2021
- IBMのWAS上のMVCフレームワークらしいが、まったく情報がない。IBMサイト上でドキュメントも見つからない。これだけ情報がないのは逆にすごい。売る気があるとは思えない
- オブジェクトサイズの計測とメモリリークの検出
- J2EE開発者にとって、「セッションは小さく」設計するのが定石ですよね。では実際にセッションサイズはどう測るのでしょうか? ほとんどの方が「予測」で済ませているのが実情です。しかし、実際に測ってみるとさまざまなことが見えてきます。
- Javaで軽快に使える軽量フレームワーク
- http://wicket.apache.org/
- 従来のフレームワークは基本的に「いかにして記述するソースコードを減らすか」を考えられていたように思えます。「さまざまな設定情報などは極力ソースコードから切り離し、テキストファイルベースの設定ファイルで記述する」「独自のテンプレートなどを駆使し、なるべくソースコードとして書かなければならない部分を減らしていく」といった考えです。
- Wicketはまったく反対です。これは「すべてをJavaで記述するフレームワーク」なのです。Wicketで作成するのは、ページのテンプレートとしてのHTMLと、Javaのソースコードだけ。作成する必要がある設定ファイルの類いは、わずかにサーブレットを登録するweb.xmlの修正だけです。HTMLファイルにしても、JSP のように特殊なタグや処理を埋め込んだりするわけでなく、ごく普通のHTMLに専用の属性を追記するだけで、後はすべてJavaで書くのです。
Servlet一般 †
- ServletConfigとは
- サーブレットの設定を取得するためのインターフェイス。
- J2EEに含まれるインターフェイスのひとつ。パッケージも含めたインターフェイス名はjavax.servlet.ServletConfig。
- HttpServletインターフェイスのgetServletConfig()メソッドでServletConfigインターフェイスの実装クラスの参照を取得することができる。
Java Webアプリケーションのデプロイメント †
- ear内のWebコンテンツのルート設定
- META-INF/application.xmlにある
- module/web/context-root
- JAR,WAR,EARファイルについて
- サーブレットや JSP の実行環境であるアプリケーションサーバの場合、WAR (Web ARchive) という単位でアプリケーションを配布/配備(適用)します。
- EAR、WAR、JAR は何れも Java 仕様に準拠して定義された ZIP 圧縮ファイルです。JAR の場合は、ここで説明したとおり、そのままクラスパスの宛先として指定できます。EARは、複数の WAR や EJB JAR を含んだ ZIP 圧縮ファイルで、 J2EE コンテナに配布すると、J2EE コンテナが解凍して実行ディレクトリにコピーします。これを配備(デプロイ)と呼んでいます。
- WAR には web.xmlが、EAR には application.xml が各々含まれており、配備方法やコンテナへの定義情報が記述されています。これらの XML ファイルは配備記述子 (DD: Deployment Descriptor) と呼ばれ、J2EE 仕様で DTD が定義されたものの他、J2EE コンテナ独自のものも存在します。
- 何れにせよ、WAR, EAR のディレクトリ構造は、J2EE 仕様で明確に決められています (J2EE 1.4仕様 8.4 Deployment)。*.ear には、一つの META-INF/application.xml と、複数の *.war と *.jar が含まれています。*.war には、WEB-INF/web.xml、WEB-INF/classes/*.class、WEB-INF/lib/*.jar、*.jsp、*.html などが存在します。
- META-INF ディレクトリ
- jarファイル(ear,war含む)の中には必ずMETA-INFディレクトリが存在する約束になっている。
- WEB-INF ディレクトリ
- warファイル内に必ず存在する
- web.xml,faces-config.xml,components.xmlなどがここに置かれる
- これとは別にMETA-INFも存在する
Webアプリの戻るボタン対策 †
- 戻るボタン対策としてキャッシュのエクスパイアをする方法は不評
- 以前はトランザクション領域で「戻る」ボタンを押すと「白い画面」になるWebアプリケーションが多く存在しました。これは、まだ不正遷移対策の仕組みが普及していなかったため、トランザクション領域のページを出力する際に、HTTPヘッダにページの有効期限(Expires)を設定することで、キャッシュを無効にし「戻る」ボタンの利用を防いでいたわけですが、一般ユーザーはエラーの意味が分からず、とても不評な対策でした。
- IEのキャッシュ制御について書かれています。ただし、FireFoxやOpera、同じIEでもバージョンによって挙動が異なるため、不正遷移対策として確実な方法ではありません。
- [戻る]ボタン押下時に、「警告:ページの有効期限切れ」というページへ遷移するようにします。例えば、Javaサーブレットを使ったWebアプリケーションの場合は、Actionクラスに下記の処理を組み込みます。
response.setHeader("Pragma","no-cache");
response.setHeader("Cache-Control","no-cache");
response.setDateHeader("Expires",0);
セッションタイムアウトについて †
- Tomcat のデフォルトのセッションタイムアウトは30分です。
- HttpSession#setMaxInativeInterval メソッド
- セッションごとにタイムアウト値を設定できる。
- セッションのタイムアウト値を「秒」で設定します。
- セッションをタイムアウトさせたくない場合は負数(0 より小さい数)を渡します。
Servletで画像のURLを見せずに直接アウトプット †
- http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=40282&forum=12&7
- メディアタイプ:image/jpeg
- 1.画像のURL(〜.jpgなど)でServletを呼び出すようにweb.xmlを編集して呼び出しテスト
- 2.1で呼び出したServletで静的ファイルから読み出した画像ファイルのバイナリ列をRequestから取得したOutputStreamに書き出しすようにし、URLを直接叩いて表示確認
- 3.2で静的ファイルから画像を読み出した部分を動的に作った画像からImageIOで作ったバイナリに変更して表示確認
- 4.3のURLを静的HTMLにimgタグで埋め込んで表示確認
- 5.4の静的HTMLをJSPにして動的コンテンツから動的画像を呼ぶようにして表示確認
- ServletAPIのJavaDoc引用
- バイナリデータを MIME のメッセージボディにセットして送り返す場合は
getOutputStream() メソッドで取得できる ServletOutputStream オブジェクトを使ってください。
- また、 文字データを送り返す場合は、getWriter() メソッドにより取得できる
PrintWriter オブジェクトを使ってください。
ファイルセーブダイアログを開いてファイルをダウンロードさせる †
request.getRemoteHost()で逆引きしない †
運用 †
|