1‐6
・init()
・destroy()
・doGet()
・doPost()
3‐1
・クッキー
・URLリライト
3‐2
・クッキー
クッキーによってセッション番号を運んでくる
・URLリライト
セッション番号の情報が後ろに付加されているアドレスを使用する
3‐4
・クッキーが有効であれば、ブラウザが自動的にセッション番号をクッキーとして運んでくるので、セッションを識別することができる。よって、同じブラウザからアクセスされた場合は、同じセッションを使用する。当然、番号も同じになる。
3‐5
・クッキーが無効であれば、ブラウザが自動的にセッション番号を運ぶということができなくなる。セッション番号をもたないアクセスは、全てそのブラウザからの初めてのアクセスとみなされる。よって、同じブラウザからアクセスされた場合も、異なるブラウザからのアクセスとみなし、その度に新しいセッションを作成する。当然、番号もその度に異なるものになる。
4‐1
・ページ(page)
・リクエスト(request)
・セッション(session)
・アプリケーション(application)
4‐2
・ページ(page)
一つのページが一つのスコープを形成する
・リクエスト(request)
ブラウザからの要求に対して応答返すまでの一往復中にアクセスしたページが一つのスコープを形成する
・セッション(session)
同じブラウザからアクセスしたページが一つのスコープを形成する
・アプリケーション(application)
同じWebアプリケーションに属するページが一つのスコープを形成する
4‐6
・アプリケーションスコープはブラウザとは無関係なスコープなので、ブラウザが再起動されても、そこに登録されたデータがなくなることはない
4‐10
・セッションスコープはブラウザに対応するスコープなので、ブラウザが再起動されれば、その後のアクセスはそれまでとは別の新しいブラウザからのアクセスとみなされる。よって、以前データが登録されいたセッションスコープではなく、新しいセッションスコープから情報を取得しようとするが、そこにはまだデータが登録されていないので、取得できるはずがない
4‐13
・リクエストスコープは、ブラウザからの要求に対して応答を返した時点で終了するので、4‐11にアクセスして戻ってきたときにはそのリクエストスコープは終了している。次に4‐12にアクセスしてリクエストスコープから情報を取得しようとするが、それは、4‐11のときのリクエストスコープとは別のものになる。よって情報の受渡しができるはずがない
4‐14
・HttpServletResponseインターフェースのsendRedirect()メソッド
指定したページにジャンプする機能だが、実際は一旦ブラウザに応答を返し、その後ブラウザから自動的に素早くそのページにアクセスしてもらう。一度ブラウザに制御が戻るので、ジャンプ先のページとリクエストスコープを共有することはできない
・RequestDispatcherインターフェースのforward()メソッド
指定したページにジャンプする機能で、上記の機能と似ているが、ブラウザに制御が戻ることはない。よって、ジャンプ先のページとリクエストスコープを共有することができる
4‐16
4‐14で確認したとおり、HttpServletResponseインターフェースのsendRedirect()メソッドでジャンプした場合、ジャンプ先のページとリクエストスコープは共有できないので、リクエストスコープを使用しての情報の受渡しはできない
4‐18
4‐14で確認したとおり、RequestDispatcherインターフェースのforward()メソッドでジャンプした場合、ジャンプ先のページとリクエストスコープを共有できるので、リクエストスコープを使用しての情報の受渡しが可能
5‐1
(1) out
(2) request
(3) response
(4) session
(5) application
5‐2
_jspService()
5‐3
(1) <%@ ... %>
(2) <%! ... %>
(3) <% ... %>
(4) <%= ... %>
(5) 特殊タグに囲まれていない部分