GitHub GitItで学んだものメモ
Git
オープンソースソフトウェア
変更を記録してくれる
バージョン管理システムとして知られる
ターミナルでいつでも使うことができる
Gitの設定
git --version
git config --global user.name "ほにゃらら"
git config --global user.email "メールアドレス"
Repositories
プロジェクトのこと
自分のプロジェクトをGitに伝えることで、そのフォルダの中のすべての変更を追跡してもらえる(バージョン管理システム)
以下例
mkdir フォルダ名
cd hello-world
git init
git status
ファイルの追加/保存/確認
git add ファイル名
git commit -m "コメント"
git diff
git add.
GitHubのアカウントを作り、Gitにユーザー名を追加
git config --global user.username ユーザ名
・GitHubに作成した名前と全く同じ名前
・大文字小文字は区別されるので注意
REMOTE
GitHubに何かをおくとそれはGitHubのサーバー上に存在していることになる(リモートリポジトリ)
自分のローカル(コンピュータのこと)の変更をpushすることでプロジェクトを最新状態に保てる
リモートにある変更をpullしてそれぞれのコンピュータに取り込みプロジェクトを最新の状態にする
お互いのコンピュータにアクセスすることなくプロジェクトメンバー同士がコードや情報を共有できる
リモートリポジトリを作る
ローカルにあるバージョンをリモートのバージョンと同期するため、空っぽのリモートリポジトリをGitHubに作る
・new repository
・ローカルリポジトリと一致する名前をつけ、短い説明をつける
・publicを選択
・readmeはプロジェクトに関する説明、どう使うか、どう貢献するかを書くもの
・.gitignoreはGitに追跡しないでほしいものの一覧(パスワードファイルなど)
・licenseファイルはプロジェクトに対するライセンスを定義する
・create repository
ローカルとリモートをつなぐ
httpsボタンを選択し、 GitHubサーバ上におけるリポジトリのアドレスをコピーする
ターミナルでGitリポジトリとして初期化したフォルダの中から、GitHubサーバ上にあるリモートバージョンの場所をGitに知らせる(別の名前をつけ複数のリモートを設定することもできる。メインのリモートサーバに対しては通常originと名付ける)
git remote add origin コピーしたURL
作業内容をリモートにPushする
Gitのブランチという仕組みは、プロジェクトの別々の箇所に対して別々のタイミングで作業できるようにするためのもの
最初のブランチはデフォルトではmasterという名前である
git push origin master
fork
リポジトリをフォークするとそのリポジトリのコピーを自分のGitHubアカウントの下に作ることになり、それはremoteリポジトリの一つとして使える
あるプロジェクトの自分自身のバージョンを作るために使用したり、元のプロジェクトに対してバグ修正や機能追加を送り返してあげるために使用する
clone(コピー)
リポジトリのコピーを自分のコンピュータ上に持ってくることができる
クローンすると新しいフォルダが作られる
別のGitリポジトリのフォルダの中にリポジトリをクローンしないように注意する
git clone コピーしたURL
ブランチ
Gitリポジトリは必要に応じてブランチを使い、隔離された作業環境を作れる
プロジェクトで作業するとき、または他人と作業するとき、ブランチを作って変更を保存する
メインのブランチを安全に保ち作業できる
作業が終わり、準備が整ったら、ブランチをmasterにマージする
ブランチを作る
ブランチを作るとGitは今いるブランチのものをすべてコピーして、新しく作ったブランチに持ってきてくれる
git status
ブランチ名は大文字小文字区別あり
git branch ブランチにつける名前
git checkout ブランチの名前
ソーシャルコーディング
他の人と共同作業が簡単にできるところがGitHubのいいところのひとつ
コラボレーターというのはGitHubのユーザでかつ誰かのリポジトリにアクセスし、編集することが許された権限を持つ人たちのこと
プロジェクトにコラボレーターを追加するにはGitHubのリポジトリページに行き、Settingをクリックする
その後Collaboratorsタブを選択、追加したいユーザ名を入力しAddをクリックする
Pull
誰かと一緒に作業していて、ファイルを最新に保ちたいという状況になったとき、pullすることで変更を取り込める
git pull リモートの名前 ブランチの名前
git fetch --dry--run
なにも変更がなければ、Already up-to-date、何か変更があればGitがそれをローカルにマージしてくれる
Pull Request
フォークしたリポジトリに変更や改善を加えたら、それらの変更を元のリポジトリのメンテナーに対して変更を元のリポジトリにpullしてほしいというrequestを送る
ローカルでマージする
git merge ブランチの名前
git checkout ブランチの名前
git branch -d ブランチの名前
git push リモートの名前 --delete ブランチの名前
git pull リモートの名前 ブランチの名前
注意点
プロジェクト名が複数単語から作られる場合ハイフンをいれる
例 shopping-site
またmysqlに接続できなくなったので対処をメモ
mysql -u root -p
から
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
で
で調べて
findコマンド使ってmysql.serverファイル探し
それでmysqlの起動はできたけど接続ができない
エラー文がこれと同じだったので、ここみて
sockファイルがないとのことだったので
sudo touch mysql.sock
でファイルを作る
sudo mysql.server restart
でmysqlを再起動
でもっかいmysql -u root -pでパスワードうって成功
最初の工程いらなかったかな
exitするたび入れなくなってて困る
なんか設定でもおかしいのかな
独習Javaサーバサイド編第2版 第10章まとめ
クロスサイトスクリプティング(XSS:CrossSiteScripting)脆弱性
エスケープ処理の不備などが原因でエンドユーザからの入力などによって生成されるページで、不正なスクリプトを混入/実行されてしまうセキュリティーホールのこと
対策
アプリケーションによって生成されるすべての値に対してHTMLエスケープ処理を施す(< > &のようなHTML予約文字を< > &のような無害な文字に置き換えること)
Functionタグライブラリのfn:escapeXml関数を利用する
SQLインジェクション
SQL命令に不正なパラメータを引き渡すことで本来開発者が意図していなかったSQL命令が生成/実行されてしまう脆弱性のこと
結果的に公開されるはずでなかった機密情報が漏洩したり重要なデータが削除されてしまう可能性がある
対策
SQLエスケープで、文字列の終了を表す'を"に置き換えることで、予約文字'を無効化する
JDBCを利用している場合、PreparedStatementオブジェクトのプレースホルだ機能を利用すると、内部的にこのようなエスケープを実行してくれる
クロスサイトリクエストフォージェリ(CDRF:Cross-Site Request Forgeries)
サイト攻撃用のスクリプトを仕込んでおくことで、アクセスしてきたユーザに意図せぬ操作を強制させる攻撃
あるサービスに勝手に登録されてしまったり、掲示板やブログに勝手に書き込みされてしまったり、ショッピングサイトで自動的に物品を購入されてしまったりする可能性がある
対策
HTTP GET要求でランダムな文字列(トークン)を生成、入力フォームに隠しフィールドとして埋め込む
トークンとはリクエストが正しいページから送信されたものか確認する一種の証明書
HTTP POSTによるリクエスト処理時にアプリケーション側で保持しているトークンと、リクエスト情報として送信されるトークンとを比較し、一致していれば処理を行う
トークンがない、一致しないときは処理を中断
トークンはランダムに生成されるので類推ができないはず、結果フォーム以外からのデータ送信を防げる
このような手法をワンタイムトークン方式という
パストラバーサル
本来想定していたパスを遡って自由にファイルを読み書きされてしまう脆弱性のこと
対策
リクエスト情報として直接ファイルのパスを受けわたさないこと
どうしてもなときはホワイトリスト(操作を許可する対象のリスト)を作るなどして、ファイル名をチェックするようにする
Cookieクラスの設定パラメータ
(1)ドメインsetDomain)/パス(setPath)
クッキーが有効となるドメイン(インターネット上にあるコンピュータやネットワークを識別する名前)/パスを指定
(2)SSL接続(setSecure)
このパラメータがtrueの場合、暗号化通信の環境でのみクッキーを送信する
(3)HTTP経由(setHttpOnly)
このパラメータをtrueに設定することでJavaScriptからクッキーにアクセスできなくなる
HTTPクッキーともいう
デフォルトはfalse
セッションハイジャック
なんらかの方法でセッションIDを盗聴することでセッションそのものを乗っ取ること
個人情報を盗まれたりなりすましによる不正な操作などの被害に直結する可能性がある
セッション関連のパラメータに適切な値を設定しておくことが大切
ファイルアップロード攻撃
不正なファイルをアップロードすることで任意のスクリプトを実行可能にできてしまう攻撃
HTTP経由でアクセスできるフォルダにファイルをアップロードさせないことで、仮に不正なファイルがアップロードされたとしてもHTTP経由で実行されてしまうことは最低限防げる
ファイルのアップロード時にファイルの種類を制限する
入力値の検証
セキュリティ対策の最初の一歩
入力時に不正な値を最大限ふるいにかけておくことで問題があった場合にもその被害を食い止められる
多重制御がセキュリティ対策の基本
検証の対象は原則リクエスト情報の全て
独習Javaサーバサイド編第2版 第9章まとめ
外部ライブラリの利用方法
Javaは標準では提供されていない機能を、外部ライブラリを追加することで簡単に実現できる
.jarファイルとその配置先
たとえばJSTLなどは外部ファイルの一種
外部ライブラリを利用するには必要な.jarファイルをアプリケーションに配置しておく必要がある
.jarとはJavaARchiveの略でライブラリの動作に必要なファイルをまとめたアーカイブ(複数のファイルをひとつのファイルにまとめること、まとめたもの。通常圧縮処理を施す)である
.jarファイルの配置先はJSP&サーブレットの場合基本的に/WEB-INF/libである
クラスローダ
クラスを管理するための基本的なエンジン
すべてのJavaアプリケーションはクラスを使用する際必ずクラスローダを介してクラスを利用する
複数のアプリケーション間でバージョンの異なる同名のクラスが必要になった場合(バージョン間で上位/下位の互換性はない場合)に対応するためTomcatのようなJSP&サーブレットコンテナでは、クラスライブラリの独立性を高めるため複数のクラスローダに階層構造をもたせている
より上位のクラスローダが優先的にクラスを呼び出す
電子メールを送信する
CommonsEmailはJavaアプリケーションから電子メールを送信するためのライブラリ
利用にはCommonsEmail本体とCommonsEmailの実行時に必要なJavaEmailをインストールしておくこと
.jarファイルを導入した後は必ずアプリケーションを再起動する必要がある
Apache Commonsプロジェクト
CommonsはTomcatやStrutsなどを輩出したことでも有名なApacheのトッププロジェクトで主にサーバサイドで利用することを目的とした拡張クラスライブラリを開発/提供している
アプリケーションにAjax機能を組み込むーDWR
Ajax技術とはブラウザ上でデスクトップアプリケーションのようなリッチな表現を可能にする技術
AjaxとはJavaScriptを利用してサーバ側と非同期通信を行い、受け取った結果をDOM(DocumentObjectModel)などの技術をつかってページに反映する仕組みのこと
従来、ユーザはサーバ処理を要求するたびにその応答を待つ必要があった(同期通信)
Ajax技術でエンドユーザはサーバ処理の間も手元の操作を継続できる(非同期通信)
また、ページ全体ではなく、実際に変更されたページの断片だけを部分的に更新するので画面のちらつきも最小限におさえられる
問題点もいくつかあり、そのためにDWRが用いられる(JavaScliptのコーディングを最小限におさえるライブラリ)
JSP&サーブレットアプリケーションとの親和性が高く、標準的なJavaBeansをAjax/非Ajaxの双方でほぼそのまま再利用できる
DWRライブラリの機能
クライアント/サーバ間の橋渡しをするためのブリッジ機能を提供するライブラリ
クライアントサイドスクリプトから、サーバサイドのJavaBeansクラスを透過的(クライアント/サーバ間で互いの通信を意識する必要がない)に呼び出せる
プロキシクラスとはDWRによって動的に生成されるJavaBeansアクセス用のJavaScriptクラスのこと
クライアント/サーバ間の通信をアプリケーションの代わりに受け持つ
PDF帳票を生成するーiText
PDF(Portable Document Format)は、無償のクライアントアプリケーションであるAdobe Readerで参照可能なドキュメント形式
改ざん防止やコピー、印刷の禁止などのセキュリティ設定が充実している、オリジナルのレイアウトを正確に再現できるといった特性から文書閲覧フォーマットのデファクトスタンダードとして急速に普及したPDFをJSP&サーブレットアプリケーションで生成するライブラリがiTextである(オープンソース)
iTextライブラリを利用するにはiText本体と、実行時に必要になるBouncyCastleライブラリが必要(セキュリティ機能を利用する場合)
独習Javaサーバサイド編第2版 第8章まとめ
アプリケーション共通の処理を定義する
フィルタ
JSPやサーブレットなどのコンテンツが呼び出される際に一緒に呼び出され、補助的な処理を行うことを目的とした仕組み(生成されたコンテンツの圧縮、暗号化、ログ集計や認証など)
ソースの維持管理という面で、効率的
フィルタクラス定義に必要な条件
①Filterインタフェースを実装する
インタフェースを実装する場合、たとえそのメソッドが不要であってもメソッド自体の記述を省略することはできない
②初期化/終了処理はinit/destroyメソッドで定義
initメソッドはフィルタが初めて呼び出されるタイミングで呼び出される
destroyメソッドはフィルタクラスが破棄されるタイミングで呼び出される
③実処理はdoFilterメソッドで定義
void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
request:リクエスト情報
response:レスポンス情報
chain:フィルターチェーン
登録された次のフィルタを実行する(次のフィルタが存在しない場合、最初にリクエストされたページを処理する)
末尾には必ずFilterChainオブジェクトのdoFilterメソッドを記述しなければならない
FilterChainは登録済みフィルタの集合(フィルタチェーン)を管理するためのオブジェクト
void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException
request:リクエスト情報
response:レスポンス情報
登録された次のフィルタを実行する(次のフィルタが存在しない場合最初にリクエストされたページを処理
リクエストデータの文字コードを宣言する
フィルタはURL指定やフォームの送信などで直接呼び出せない
web.xmlでフィルタがどのページで呼び出したタイミングで起動されるべきか宣言する必要がある
①フィルタ名とクラス名を関連づける
クラス名とファイル名は全く違くてもよい
定義されたファイル名は
String getInitParameter(String name)
name:初期化パラメータ名
デプロイメントディスクリプタで定義された初期化パラメータを取得する
②フィルタの適用範囲を決める
WebFilterアノテーションでフィルタを宣言する
@WebFilter(
urlPatterns= { URLパターン,... },
servletNames = { サーブレット名,...},
initParams = {
@WebInitParam(name = "パラメータ名", value = "値"),
@WebInitParam(name = "パラメータ名", value = "値"),...
},
dispatcherType = { ディスパッチャー,... }
}
リスナクラスでアプリケーションイベントを補足する
アプリケーションイベント
アプリケーションやセッション開始/終了、セッション/リクエスト属性の登録/削除など、アプリケーションの中で発生するイベントのこと
リスナはそれに対しなんらかの処理を行うクラスで、あらかじめ決められたタイミングでさまざまな共通処理を実行できる
リスナクラスを定義するには目的に応じて必要なインタフェースを実装する必要がある
Webistenerアノテーションでリスナを宣言する
@WebListenerアノテーションを利用することでweb.xmlレスでリスナを登録できる
アプリケーション開始時に必要なリソースをロードする
web.xmlの解析はそれなりに負荷の高い処理で、リクエストのたび読み込みにいくのは好ましくない
アプリケーション起動時にメモリにロードしてしまえばデータ読み込みの負荷を軽減できる
自作のタグライブラリを定義する
自作のアクションタグ(カスタムタグ)を作る
カスタムタグの実際の挙動を定義するのはタグハンドラクラス
・基本クラスを継承する
・タグの具体的な動作はdoStartTag/doEndTagメソッドで定義
・属性を設定するのはセッタメソッドの役割
・処理結果を出力するのはJspWriterクラス
タグライブラリディスクリプタを定義する
タグライブラリディスクリプタ(タグライブラリ記述子)とはカスタムタグに関する基本情報を記述するためのファイル
カスタムタグを定義したタグハンドラクラスと実際のタグ名とを関連づけ、同時にカスタムタグで利用可能な属性や本体などの情報を定義する
ファイル名は自由
拡張子は.tld配置先は/WEB-INF/taglibsフォルダとする必要がある
①ルート要素は
②タグライブラリの基本情報を定義する
③カスタムタグの仕様を定義する
タグライブラリディスクリプタの配置場所
標準以外のフォルダに配置したいときは、タグライブラリディスクリプタの検索先をデプロイメントディスクリプタに登録しておく
静的メソッドを式言語から呼び出す
JSP2.0以降、式言語を介してJavaの静的メソッドを呼び出すことができるようになった(Function,関数)
利用することで簡単な演算やデータ加工などのコードを.jspファイルからとりのぞける
システムプロパティを表示する関数を定義する
関数を動作させるのに必要なファイル
・静的メソッドを定義したクラスファイル(関数本体)
・タグライブラリディスクリプタ(.tldファイル)
・関数を呼び出すためのJSPページ
Functionから呼び出すメソッドを定義する際の注意
・静的メソッドとして定義すること(staticキーワードを付与すること)
・アクセス修飾子としてpublicを指定すること
カスタムタグと関数の使い分け
カスタムタグと関数は与えられタパラメータに基づいて、なにかしらの結果を返すという似たような役割を持っている
どちらもビュー層で利用できる
①戻り値をどのように使用するか
Function:そのままほかのカスタムタグの属性値として指定できる
カスタムタグ:タグどうしを入れ子にできるが直接の属性値としては指定できない
②引数の多寡
Function:カンマ区切り
カスタムタグ:属性値="値"
③引数の内容
Function:何行にもわたる文字列は苦手
カスタムタグ:長い引数でもスマートに表現可能
④暗黙オブジェクトへのアクセスが必要か
Function:ユーザの目的に直接関係しない引数を明示的に渡さなければならない
独習Javaサーバサイド編第2版 第7章まとめ
デプロイメントディスクリプタ
(DeploymentDescriptor:配列記述子)はJSP&サーブレットにおける標準の設定ファイル
Webアプリケーションの配置情報を記述したxml形式の設定ファイル
Tomcatではweb.xmlという名前になる
アプリケーションルート配下の/WEB-INFフォルダに配置する
サーブレットの登録やセッション情報の設定、アプリケーションレベルの初期化パラメーターやウェルカムページ、エラーページ、認証の定義などアプリケーション全体にかかわる項目を設定できる
デプロイメントディスクリプタの基本
XMLの基本構文
XML(eXtensibleMarkuoLanguage)は標準化団体であるW3C(WorldWideWebConsortium)によって策定された拡張可能なマークアップ言語
HTMLに似たタグの形式で構造化されたデータを記述できる
1.主に要素と属性から構成される
要素:
属性:タグ内に属性名="属性値"のセットで記述され、要素が表す情報に対して付随的な情報を記述するのが一般的。タグ内にいくつでも記述できる
<要素名 属性名="属性値"...>任意のデータ</要素名>
要素名及び属性名は目的に応じて自由に決められる
2.XML文書であることを宣言しなければならない
先頭行に<?xml ?>を記述する
<?xml version="1.0" encoding="UTF-8" ?>
version属性はXMLのバージョンを、encoding属性はファイル内の文字コードを示す
使用している文字コードがUTF-8のとき宣言は省略可
3.必ず開始タグで始まり、終了タグで終わらなければならない
終了タグを省略したい場合~/>で閉じる
4.すべての要素は正しくネスト構造になっていなければならない
5.唯一のルート要素を持たなければならない
XML文書の最上位には必ずルート要素(ドキュメント要素とも)がなければならない
6.要素/属性名の大文字/小文字は区別される
7.属性値はダブルクォートまたはシングルクォートで囲まなければならない
要素名と属性名の間は必ず半角スペースで区切る
8.コメントは<!--~-->で表す
コメントの中にコメントを入れ子で記述することはできない
web.xmlの配置先
2種類のレベルがあり、配置先が異なる
conf/web.xmlをアプリケーション開発者が編集すべきではない理由
●conf/web.xmlへの設定はすべてのアプリケーションに影響する
●アプリケーションを異なるサーバに配置した時に、配置先でもまたconf/web.xmlを編集し直さなければならない
特別な理由がない限りアプリケーション開発者は個々のアプリケーション配下のweb.xmlのみを編集するようにする
web.xmlの骨組み
デプロイメントディスクリプタのルート要素は< web-app>要素である
配下に子要素を含むことができる
初期化パラメータを定義する< context-param>要素
アプリケーション共通で利用可能な初期化パラメータを宣言する
リソースのパス、データベースへの接続情報、文字コード名などアプリケーションの複数箇所から共通して参照する可能性があり、かつ環境によって変動するような情報を指定しておく
アプリケーション配下のすべてのJSP&サーブレットから参照できる
初期化パラメータを取得する
<context-param>
<param-name> 初期化パラメータ名
<param-value> パラメータ値
<description>* パラメータの概要
初期化パラメータにアクセスする手段を提供するのはServletContextインタフェースのgetInitParameterメソッドである
式言語利用の場合はServletContextインタフェースの代わりに暗黙オブジェクトinitParamを使用する
String getInitParameter(String name)
name:初期化パラメータ名
<context-param>要素で定義した初期化パラメータを取得する
JSTLで利用可能な初期化パラメータ
JSTLではいくつかの初期化パラメータが用意されていて、web.xmlで管理できる
カスタムエラーページを設置する要素
アプリケーションで処理されない例外が発生した場合に表示されるエラー通知画面
404などの情報をみてもエンドユーザにはわかりにくいのと、クラッカーに情報を悪用されるのを防ぐためカスタムのエラーページを定義するのが一般的
<error-page>
<error-code> エラーコード(HTTPステータスコード)
<exception-type> 例外クラスの完全修飾名(<error-code>といずれかを設定)
<location> <error-code>または<exception-type>の設定に応じて表示するエラーページ
カスタムエラーページを定義する
アプリケーション内部の構造を漏洩する可能性がある例外情報をクライアントに出力することは好ましくないが、これらの情報がどこにもないと、障害対応することもできないので裏でログとして記録する必要が有る
ログをテキストファイルとして記録する場合、エンドユーザからアクセスできないように/WEB-INFフォルダの配下に保存する
アプリケーションに認証機能を実装する
フォーム認証
ログイン画面を自由にレイアウトできる
認証の状態はセッションで管理されている
ログアウトするにはlogoutメソッドを呼び出す(サーブレット3.0から)
request.logout();
2.5以前ではinvalidateメソッドを利用する
session.invalidate();
フォーム認証機能を実装する
フォーム認証を実装するのに必要なファイル
●デプロイメントディスクリプタ(web.xml)
web.xmlの設定は< security-constraint>(制限ルール)、< login-config>(ログイン方法)、< security-role>(権限の宣言)の3ブロックに分かれる
●ユーザ情報ファイル(tomcat-users.xml)
ロール(権限)とはあるリソースへのアクセスの可不可を表す一種のユーザグループ
●ログインページ
ユーザ名/パスワードを表すフォーム要素のnameオプション、< form>タグのactionオプションの値にはあらかじめきれられたキーワードを設定する
●ログインエラーページ
htmlで書いてもいい
アクセス規則をアノテーションで記述する
ページ単位の細かなアクセス管理をしたいという場合利用する
@ServletSecurity(
@HttpConstraint(rolesAllowed = { 許可するロール名,... })
)
ユーザ情報をデータベースで管理する
1.DataSourceRealmを有効にする
2.ユーザ管理のためのテーブルを用意する
3.デプロイメントディスクリプタやログインページを用意する
独自のログインページを実装する
1.認証サーブレットを用意する
2.ログインページを修正する
@page/@taglibディレクティブの記述を省力化する
JSPページ内で日常的にタグライブラリを利用するようになるとページごとに@taglibディレクティブを記述するのが面倒になる
JSP2.0からJSPコンフィギュレーション(JSP構成)という仕組みが用意された
JSPページの共通設定やコードを.jspファイルから切り離して1箇所で管理できるようになる
共通のヘッダファイルを定義する
JSPコンフィギュレーションは
設定できる内容は大きく「JSPページの共通設定」と「タグライブラリの登録」に分類できる
< scripting-invalid>要素
スクリプティング要素の利用を禁止する
< el-ignored>要素
式言語を無視する
ウェルカムページを定義する
< welcome-file-list>要素を設定しておくとデフォルトページを優先的に表示する
エンドユーザによるURL入力の手間を軽減できる
ウェルカムページを設定する
<welcome-file-list>
<welcome-file>+ ウェルカムページとするファイル名
複数の要素を指定できる
バージョンによる挙動の違い
4.xまで:404NotFoundエラーを返すだけ
5.0以降:デフォルトサーブレット(値が/である< ulr-pattern>要素に関連づけられたサーブレット)を検索しようとする
デフォルトサーブレットとは値が/である< url-pattern>要素に関連付けられたサーブレットのこと
Tomcatサーバを管理するーserver.xml
server.xmlはTomcatサーバを管理するためのTomcat固有の設定ファイルで、デプロイメントディスクリプタと同じくXML形式で記述する
< server>要素を頂点として、サーバの論理的な階層構造を表す
仮想ホストとは1つのサーバであたかも複数のホストが存在するかのように見せかける仮想的な仕掛けのことで、1つのサーバ内でURLをわけて運用することが可能になる
サーバ/クライアント間の接続を管理する< Connector>要素
< Connector>要素はサーバ/クライアント間の接続を管理するコネクタを定義する
Tomcatではport属性で指定されたポート番号によってどのコネクタで処理を行うか決定する
ポート番号が8009であるコネクタはApacheなどのWebサーバを経由したリクエストを受け付けるためのコネクタ
アプリケーションの配布ー.warファイル
アプリケーションルート配下のサブフォルダ/ファイル全体を圧縮したアーカイブ
決められたフォルダに配置するだけでアプリケーションを利用できる
< Context>要素
アプリケーション単位の情報を定義する
< Valve>要素
Valve(バルブ)とは、Tomcatに対する要求のタイミングで、なんらかの処理を割り込ませる仕組みのこと
アプリケーションのロギングやアクセス制限などを設定ファイルの記述だけで実現できる
独習Javaサーバサイド編第2版 第6章まとめ
●サーブレットの必要性
アプリケーションを構築する場合、ただ動けば良いのではなく、長期的に修正したり改造したりすることを考慮し、メンテナンスしやすいコードを書く必要がある
そのキーとなるのがサーブレットである
●暗黙オブジェクト
●サーブレットの骨格
java.io,javax.servlet,javax.servlet.httpパッケージは必須
javax.servletおよびjavax.servlet.httpパッケージに属する4つのクラスはJSPでは自動的にインポートされるがサーブレットでは明示的にする必要がある
HttpServletクラスを継承すること
サーブレットがクライアントと通信を行うための最低限の手続きを定めた基本クラス
サーブレットの起点はdoXxxxxメソッド
サーブレットのエントリポイントとなるメソッド
エントリポイント とはクラスが呼び出されたタイミングで最初に実行されるメソッド
一般的によく使うのはdoGetかdoPostメソッド
protected void doXxxxx(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
request:リクエスト情報
response:レスポンス情報
リクエストの実処理を定義する
XxxxxはGet,Post,Delete,Head,Options,Put,Traceのいずれか
@WebServletアノテーションを宣言する
サーブレットを呼び出すためのパス(URL)を宣言する
引数には呼び出しのパスを、アプリケーションルートからの絶対パスで指定
サーブレットをフォームから起動する
直接URLを指定してページを要求するとき、クライアントはサーバに対してGETという要求メソッドを送信している
その場合呼び出されたサーブレットはまずdoGetというメソッドを実行する