![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-06-20T16:24:27+09:00","default:irrp","irrp") #author("2023-07-18T11:50:13+09:00","default:irrp","irrp") →Java関連 →Java関連Tips →Webアプリ開発 →Webサーバ #contents *サブトピック [#r8f9d909] -Spring Framework関連 --Spring Boot関連 -JSF(JavaServer Faces)関連 -JSP関連 -Struts関連 -SAStruts関連 -JBoss Seam関連 *一般記事 [#ifacfe67] -[手軽に学ぶ！初心者向けJavaアプリのAWSデプロイ方法。Eclipse、Tomcat、Apacheで始めるクラウド運用。 - Qiita>https://qiita.com/shuncask/items/779d8e92cc7af63aaa94]] 2023.6 -[[eclipse + Tomcat + MySQL + Javaを使用して動的Web作成してみた - Qiita>https://qiita.com/usamaro/items/83de0d8733561661dd5b]] 2023.3 -[[WACsについて>http://taka-hama.sakura.ne.jp/prg_memo/java/wacs/000.html]] 2021 --IBMのWAS上のMVCフレームワークらしいが、まったく情報がない。IBMサイト上でドキュメントも見つからない。これだけ情報がないのは逆にすごい。売る気があるとは思えない -[[オブジェクトサイズの計測とメモリリークの検出>http://codezine.jp/article/detail/1633]] --J2EE開発者にとって、「セッションは小さく」設計するのが定石ですよね。では実際にセッションサイズはどう測るのでしょうか？ ほとんどの方が「予測」で済ませているのが実情です。しかし、実際に測ってみるとさまざまなことが見えてきます。 -[[WebSphere MQ>http://ja.wikipedia.org/wiki/WebSphere_MQ]] --WebSphere MQ は、IBMが開発・販売する、メッセージングミドルウェアである。 --[[WebSphere MQ 入門書>http://www.ibm.com/developerworks/jp/websphere/library/wmq/mq_intro/]] 2014.6 -[[本格的なRoRスタイルフレームワーク「Play!」（1）>http://codezine.jp/article/detail/4750]] 2010.1.22 -[[低い学習コストを重視した「Apache Click」 （1） >http://codezine.jp/article/detail/4555]] 2009.11.27 -[[Javaで軽快に使える軽量フレームワーク>http://codezine.jp/article/detail/4459]] --http://wicket.apache.org/ --従来のフレームワークは基本的に「いかにして記述するソースコードを減らすか」を考えられていたように思えます。「さまざまな設定情報などは極力ソースコードから切り離し、テキストファイルベースの設定ファイルで記述する」「独自のテンプレートなどを駆使し、なるべくソースコードとして書かなければならない部分を減らしていく」といった考えです。 --Wicketはまったく反対です。これは「すべてをJavaで記述するフレームワーク」なのです。Wicketで作成するのは、ページのテンプレートとしてのHTMLと、Javaのソースコードだけ。作成する必要がある設定ファイルの類いは、わずかにサーブレットを登録するweb.xmlの修正だけです。HTMLファイルにしても、JSP のように特殊なタグや処理を埋め込んだりするわけでなく、ごく普通のHTMLに専用の属性を追記するだけで、後はすべてJavaで書くのです。 *Servlet一般 [#e9a6e5c1] -[[実はサーブレットの勉強もSpring Bootを使うほうが楽なのでは - きしだのHatena>https://nowokay.hatenablog.com/entry/2023/07/16/130325]] 2023.7 -[[サーブレットを「JavaでのWebアプリケーションの基礎」として最初に勉強させるのをやめてあげてほしい - きしだのHatena>https://nowokay.hatenablog.com/entry/2023/07/15/213831]] 2023.7 -[[サーブレットのインスタンス変数はマルチスレッドを前提とすること>http://www.itarchitect.jp/technology_and_programming/-/27082-3.html]] -[[ServletConfigとは>http://www.kab-studio.biz/Programing/JavaA2Z/Word/00000828.html]] --サーブレットの設定を取得するためのインターフェイス。 --J2EEに含まれるインターフェイスのひとつ。パッケージも含めたインターフェイス名はjavax.servlet.ServletConfig。 --HttpServletインターフェイスのgetServletConfig()メソッドでServletConfigインターフェイスの実装クラスの参照を取得することができる。 *Java Webアプリケーションのデプロイメント [#v9f133c8] -ear内のWebコンテンツのルート設定 --META-INF/application.xmlにある --module/web/context-root -[[J2EEアプリケーションと配置>http://www.atmarkit.co.jp/fjava/rensai/j2ee03/j2ee03.html]] -[[J2EEアプリケーションを構成するコンポーネント>http://www.atmarkit.co.jp/fjava/rensai/j2ee04/j2ee04.html]] -[[web.xmlとは？>http://www.hellohiro.com/servletwebxml.htm]] --WEBアプリケーションの設定を記述するファイル --WARファイル内にある -application.xml --EARファイル内にある -[[JAR,WAR,EARファイルについて>http://www.nextindex.net/java/jar.html]] --サーブレットや 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アプリの戻るボタン対策 [#i718b6db] -戻るボタン対策としてキャッシュのエクスパイアをする方法は不評 --http://codezine.jp/article/detail/2627?p=4 -以前はトランザクション領域で「戻る」ボタンを押すと「白い画面」になる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); *セッションタイムアウトについて [#g20e1433] -http://ash.jp/java/webapp_session.htm --セッションのタイムアウト Webアプリケーションでは、コンテナがセッションを行 います。 --HTTPプロトコルでは、セッションという概念はありませんので、タイムアウト時間に よりセッションを切断します。セッションのタイムアウト時間（分単位）は、デプロイメント記述子（web.xml）に設定します。 --利用者が、ログイン、ログアウトしないシステムでは、タイムアウトするまで、セッション変数は残りリソースを消費します。ですから、インターネットなどに公開するシステムの場合、タイムアウト値は3分から5分ぐらいの短い値に設定します。社内システムのように、利用者が、ログイン、ログアウトをする場合は、30分や1時間ぐらいに設定しても、問題ありません。 --web.xml <session-config> <session-timeout>5</session-timeout> </session-config> --Tomcat のデフォルトのセッションタイムアウトは３０分です。 --HttpSession#setMaxInativeInterval メソッド ---セッションごとにタイムアウト値を設定できる。 ---セッションのタイムアウト値を「秒」で設定します。 ---セッションをタイムアウトさせたくない場合は負数（0 より小さい数）を渡します。 *Servletで画像のURLを見せずに直接アウトプット [#w45c8fe0] -http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=40282&forum=12&7 -メディアタイプ：image/jpeg -１．画像のURL（〜.jpgなど）でServletを呼び出すようにweb.xmlを編集して呼び出しテスト -２．１で呼び出したServletで静的ファイルから読み出した画像ファイルのバイナリ列をRequestから取得したOutputStreamに書き出しすようにし、URLを直接叩いて表示確認 -３．２で静的ファイルから画像を読み出した部分を動的に作った画像からImageIOで作ったバイナリに変更して表示確認 -４．３のURLを静的HTMLにimgタグで埋め込んで表示確認 -５．４の静的HTMLをJSPにして動的コンテンツから動的画像を呼ぶようにして表示確認 -ServletAPIのJavaDoc引用 --バイナリデータを MIME のメッセージボディにセットして送り返す場合は getOutputStream() メソッドで取得できる ServletOutputStream オブジェクトを使ってください。 --また、 文字データを送り返す場合は、getWriter() メソッドにより取得できる PrintWriter オブジェクトを使ってください。 -参考資料２:http://codezine.jp/article/detail/1021?p=1 // イメージの出力 ServletOutputStream sos = null; response.setContentType("image/jpeg"); sos = response.getOutputStream(); ImageOutputStream ios = ImageIO.createImageOutputStream(sos); ImageWriter iw = (ImageWriter)ImageIO. getImageWritersByFormatName("jpeg").next(); iw.setOutput(ios); iw.write(im); *ファイルセーブダイアログを開いてファイルをダウンロードさせる [#v3aa5ff6] -octet-streamで出力するのがポイント -http://kamakura.cool.ne.jp/oppama/ssja/struts-download.html *request.getRemoteHost()で逆引きしない [#c4c41626] -http://d.hatena.ne.jp/w650/20080521/p1 -アクセスログなど用途でホスト名を取得するため、request.getRemoteHost()を呼び出すと非常に時間がかかってしまう場合があります。 -DNSにて逆引きの設定がされていなかったりで、タイムアウトしているような場合 *IPアドレスからホスト名を取得 [#i013fbf0] -java.net.InetAddressクラスをインポート -IPアドレスの４つの数字を下記のように割り当て （例） InetAddress.getByAddress(new byte[]{(byte)192,(byte)168,(byte)0,(byte)1}).getHostName() *運用 [#y9fbd0b4] -[[Java EEサーバからレスポンス返らず。何から調べる？>http://www.atmarkit.co.jp/fjava/rensai4/trouble_knowhow01/01.html]]
