またmysqlに接続できなくなったので対処をメモ

mysql -u root -p
から
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

weekend-it.blog.jp


で調べて
findコマンド使ってmysql.serverファイル探し
それでmysqlの起動はできたけど接続ができない

 

qiita.com


エラー文がこれと同じだったので、ここみて

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はTomcatStrutsなどを輩出したことでも有名な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メソッドで定義

doFilterメソッド(Filterインタフェース)
void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
request:リクエスト情報
response:レスポンス情報
chain:フィルターチェーン
登録された次のフィルタを実行する(次のフィルタが存在しない場合、最初にリクエストされたページを処理する)

末尾には必ずFilterChainオブジェクトのdoFilterメソッドを記述しなければならない
FilterChainは登録済みフィルタの集合(フィルタチェーン)を管理するためのオブジェクト

doFilterメソッド(FilterChainインタフェース)
void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException
request:リクエスト情報
response:レスポンス情報
登録された次のフィルタを実行する(次のフィルタが存在しない場合最初にリクエストされたページを処理

リクエストデータの文字コードを宣言する

フィルタはURL指定やフォームの送信などで直接呼び出せない
web.xmlでフィルタがどのページで呼び出したタイミングで起動されるべきか宣言する必要がある
①フィルタ名とクラス名を関連づける
要素の役割
クラス名とファイル名は全く違くてもよい
定義されたファイル名は要素の中でフィルタの適用範囲を設定する際に使用する
要素にはフィルタクラス内で利用可能な初期化パラメータを指定する

getInitParameterメソッド(FilterConfigインタフェース)
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を使用する

getInitParameterメソッド(ServletContextインタフェース)
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で書いてもいい

アクセス規則をアノテーションで記述する

ページ単位の細かなアクセス管理をしたいという場合利用する

@SecurityServletアノテーション
@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>+     ウェルカムページとするファイル名

複数の要素を指定できる

バージョンによる挙動の違い

要素が指定されたウェルカムページが見つからなかった場合の動作がTomcat4.xまでと5.0以降で違う
4.xまで:404NotFoundエラーを返すだけ
5.0以降:デフォルトサーブレット(値が/である< ulr-pattern>要素に関連づけられたサーブレット)を検索しようとする
デフォルトサーブレットとは値が/である< url-pattern>要素に関連付けられたサーブレットのこと

Tomcatサーバを管理するーserver.xml

server.xmlTomcatサーバを管理するためのTomcat固有の設定ファイルで、デプロイメントディスクリプタと同じくXML形式で記述する
< server>要素を頂点として、サーバの論理的な階層構造を表す
仮想ホストとは1つのサーバであたかも複数のホストが存在するかのように見せかける仮想的な仕掛けのことで、1つのサーバ内でURLをわけて運用することが可能になる

サーバ/クライアント間の接続を管理する< Connector>要素

< Connector>要素はサーバ/クライアント間の接続を管理するコネクタを定義する
Tomcatではport属性で指定されたポート番号によってどのコネクタで処理を行うか決定する
ポート番号が8009であるコネクタApacheなどのWebサーバを経由したリクエストを受け付けるためのコネクタ

アプリケーションの配布ー.warファイル

アプリケーションルート配下のサブフォルダ/ファイル全体を圧縮したアーカイブ
決められたフォルダに配置するだけでアプリケーションを利用できる

< Context>要素

アプリケーション単位の情報を定義する
要素は独立した設定ファイル(コンテキスト定義ファイル)として記述することが推奨されている

< Valve>要素

Valve(バルブ)とは、Tomcatに対する要求のタイミングで、なんらかの処理を割り込ませる仕組みのこと
アプリケーションのロギングやアクセス制限などを設定ファイルの記述だけで実現できる

独習Javaサーバサイド編第2版 第6章まとめ

サーブレットの必要性

アプリケーションを構築する場合、ただ動けば良いのではなく、長期的に修正したり改造したりすることを考慮し、メンテナンスしやすいコードを書く必要がある
そのキーとなるのがサーブレットである

●暗黙オブジェクト

JSPによって自動的にインスタンス化されたオブジェクト

サーブレットの骨格

java.io,javax.servlet,javax.servlet.httpパッケージは必須

javax.servletおよびjavax.servlet.httpパッケージに属する4つのクラスはJSPでは自動的にインポートされるがサーブレットでは明示的にする必要がある

HttpServletクラスを継承すること

サーブレットがクライアントと通信を行うための最低限の手続きを定めた基本クラス

サーブレットの起点はdoXxxxxメソッド

サーブレットのエントリポイントとなるメソッド
エントリポイント とはクラスが呼び出されたタイミングで最初に実行されるメソッド
一般的によく使うのはdoGetかdoPostメソッド

doXxxxxメソッド
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というメソッドを実行する

からページを要求する場合、クライアントはサーバに対してPOSTという要求メッセージを送信する
その場合呼び出されたサーブレットはdoPostメソッドを実行する
どのような場合にクライアントがGET要求あるいはPOST要求を発行するか

・doGetメソッドが呼び出されるケース
ブラウザから直接URLで指定した場合
ページ内のリンクから呼び出された場合
HTMLフォームの

タグでGET形式でページを要求した場合(
またはmethodオプションが無指定)
・doPostメソッドが呼び出されるケース
HTMLフォームの
タグでPOST形式でページを要求した場合(
)

JSP固有の要素に代わるもの

コンテンツタイプを指定する

@pageディレクティブのcontentType属性に相当する部分

response.setContentType("text/html;charset=UTF-8");

JSPページからでも呼び出せるが、コンテンツタイプが正しく認識されるためにはoutオブジェクトが生成される前にsetContentTypeメソッドをコールしなければならないので正しく認識されなくなる

暗黙オブジェクトを取得する

任意の文字列を出力するにはPrintWriterオブジェクトのprintメソッドまたはprintlnメソッドを呼びだす必要がある
暗黙オブジェクトに相当するが、サーブレットではそのまま使用することはできないので明示的にオブジェクトを生成する

スクリプトレットと宣言部

インスタンス変数:初めてサーブレットが呼び出されたとき初期化され、コンテナ起動間ずっと有効な変数
ローカル変数:処理の都度破棄される変数

シングルインスタンス・マルチスレッド

サーブレットの世界では、リソースの節約という観点からいったんインスタンス化したサーブレットクラスをそのままメモリ上に常駐し、同じサーブレットに対するリクエストは同じインスタンスで処理される(ひとつのインスタンスで複数のリクエストを処理する)

サーブレットのライフサイクル

initメソッドとdestroyメソッド

サーブレットの初回起動時、アンロード/更新時にだけ実行される
すべてのリクエストで共通して利用するようなリソースはinitメソッドで初期化しておくことでリソース読み込みのオーバーヘッドを軽減できる
初期化処理を必要になるまで行わないことを 遅延初期化 という

初期化パラメータを取得する

設定ファイルで定義可能な変数で、使用する環境によって変更する可能性の高い情報(パスや文字コードなど)を定義するために使用する

初期化パラメータをアノテーションで設定する
@アノテーション名(
    属性名 = 値,
    属性名 = 値,...
)
WebServletアノテーション(initParams属性)
@WebServlet(
    initParams = {
    @WebInitParam(name = "パラメータ名",value = "値"),
    @WebInitParam(name = "パラメータ名",value = "値"),...
    }
)

サーブレットのより高度な話題

ファイルのアップロード機能実装

・enctypeオプションを指定
・MultipartConfigアノテーションでアップロード設定する
・ファイルをアップロードする

getapartメソッド
Part getPart(String name)
throws OPException, IllegalStateException, ServletException
name:パラメータ名
指定されたパラメータ名に対応するファイルを取得する
Writeメソッド
void write(String fileName) throws IOException
fileName:保存先のパス
現在のファイルを指定されたパスに保存

・Partオブジェクトからファイル情報を取得する
・アップロードファイルの種類をチェック
・URLパターンのワイルドカード指定
すべてのリクエストを1つのサーブレットで受け取るサーブレットのことを フロントコントローラ という
・フロントコントローラを定義する
getPathInfoメソッドで取得できる部分を拡張パス情報とよぶ(クエリ情報に近い)
・コンテナ起動時にサーブレットを初期化する

アプリケーションフレームワーク

フレームワークとはアプリケーションを開発するときのテンプレートのようなもの
開発生産性の向上が見込める

JSP&サーブレットの連携

サーブレットの処理結果をJSPページで表示する
リクエスト属性

ひと連なりのリクエスト処理の中で保持可能な変数

setAttributeメソッド(HttpServletRequestインターフェース)
void setAttribute(String name, Object value)
name:属性名
value:変数
指定された変数をリクエスト属性に登録する
forwardメソッド(RequestDispatcherインターフェース)
void forward(ServletRequest request, HttpServletReaponse response) throws
ServletException, IOException
request:リクエスト情報
response:レスポンス情報
指定されたページにリクエスト処理を転送する
getRequestDispatcherメソッド(ServletContextインターフェース)
RequestDispatcher getRequestDispatcher(String path)
path:アプリケーションルート/で始まるパス
指定されたパスに処理を転送するためのRequestDispatcherオブジェクトを取得する

リダイレクト

いったんレスポンスをクライアントに返したうえで自動的にサーバにリクエストを発生させる仕組み
内部的にはサーバ/クライアント間で通信の行き来が2往復発生していることになる
2回目のリクエストはサーバ側で待ち行列の末尾に配置されるので遅延が発生することもある

フォワード

サーバ内で処理を異なるページ(クラス)に転送する
サーバ/クライアント間では1度しか処理が発生しない

リダイレクトとフォワード

フォワードのほうがリダイレクトより高いパフォーマンスが望める
・リクエスト情報を引き継げるのはフォワードのみ
フォワードを利用できるのはサーバ内部の転送においてのみ(http://~で表さなければならないURLにはリダイレクトを使用する必要がある)

リクエスト情報の参照(JSP)

サーブレットクラスでリクエスト属性が設定できたらJSPページから参照する

変数のスコープ

変数の有効範囲のこと

●JavaBeans

クラスをより汎用的に部品化できるようにちょっとしたルール付けをした結果できたクラスという感じ

JavaBeansが必要な理由

性質の異なるコードを一つにまとめるとコードの再利用を阻害することになる
本来のデータ処理機能とそのほかの入力データの処理、処理結果の引き渡し機能とをさらに分離する必要がある
このような設計のことを MVC(Model-View-Controller)モデル といいJSP&サーブレットアプリケーションを構築する際一般的に採用される
MVCモデルではJavaBeans具体的なビジネスモデル(Model)を記述し、JSPユーザインタフェース(View)を実装し、両者へのデータの引き継ぎ及び割り振りをサーブレットが制御する(Controller)というように役割を明確に分担する

JavaBeansクラスの条件

1.引数のないコンストラクタを持つこと
コンストラクタをはクラスがインスタンス化される際最初に呼び出される特別なメソッドでクラスと等しい名前をもつ
オブジェクトの初期化処理を記述するのが一般的
JavaBeansでは引数をもたせてならない
2.プロパティを参照/設定するためのアクセサメソッドを定義すること
JavaBeansに保持するインスタンス変数は原則的にprivate変数として定義しなければならない(外部クラスからはJB内部のインスタンス変数に直接アクセスできない)
代わりにsetXxxxx/getXxxxxという名前のメソッドを介して行えるようにしておく(アクセサメソッド)
アクセサメソッドによって外部から隠蔽(カプセル化)されたフィールドのことを プロパティ という

アクセサメソッド
public データ型 get<プロパティ名>() {
 return this.プライベート変数名;
}...参照用メソッド

public void set<プロパティ名>(データ型 引数){
 this.プライベート変数名 = 引数;
}...設定用メソッド

読み書きの制御が可能、値の参照/設定時に任意の処理を記述できるなどのメリットがある

3.Serializableインターフェースを実装すること
そのクラスがシリアル化可能であることを表す
シリアル化とは直列化という意味でオブジェクトからバイト列への変換のこと(逆を復元という)
データの共有を目的としたJavaBeansでは汎用的なデータ交換の仕組みを備えている必要がある

JSTLをダウンロードしたところ

http://jstl.java.net/download.html

教科書ではこれからダウンロードってなっていたのだけれど

行ってみたらなんかsorryってなっていたので調べることに。

 

よくわからぬままここから頂いたけど動作に問題はないので大丈夫だと思う

最新バージョンもあるみたいだけどとりあえず教科書に合わせてver1.2.1

・javax.servlet.jsp.jstl1.2.1.jar

・javax.servlet.jsp.jstl-api-1.2.1.jar

この二つをダウンロードした

https://mvnrepository.com/artifact/org.glassfish.web/javax.servlet.jsp.jstl/1.2.1

 

ダウンロード後はEclipseのプロジェクトのWEB-INF/libってとこにふたつとも置いて完了