■tomcat起動

su -s /bin/bash -c "/usr/local/tomcat8/bin/startup.sh" tomcat

 

■tomcat終了

su -s /bin/bash -c "/usr/local/tomcat8/bin/shutdown.sh" tomcat

 

■tomcatのlistening port

せ7> netstat -npatl | grep java
tcp6       0      0 :::8080                 :::*                    LISTEN      3864/java
tcp6       0      0 127.0.0.1:8005       :::*                   LISTEN      3864/java
tcp6       0      0 :::8009                 :::*                    LISTEN      3864/java

 

■tomcatのWebアプリケーションマネージャ

tomcat管理ページインストール

・設定

何にも設定せずにブラウザから下記にアクセスると、

http://192.168.2.7:8080/manager/html

ブラウザに下記のようなレスポンスページが表示される

403 Access Denied
You are not authorized to view this page.
By default the Manager is only accessible from a browser running on the same machine as Tomcat. If you wish to modify this restriction, you'll need to edit the Manager's context.xml file.
If you have already configured the Manager application to allow access and you have used your browsers back button, used a saved book-mark or similar then you may have triggered the cross-site request forgery (CSRF) protection that has been enabled for the HTML interface of the Manager application. You will need to reset this protection by returning to the main Manager page. Once you return to this page, you will be able to continue using the Manager application's HTML interface normally. If you continue to see this access denied message, check that you have the necessary permissions to access this application.
If you have not changed any configuration files, please examine the file conf/tomcat-users.xml in your installation. That file must contain the credentials to let you use this webapp.
For example, to add the manager-gui role to a user named tomcat with a password of s3cret, add the following to the config file listed above.
<role rolename="manager-gui"/>
<user username="tomcat" password="s3cret" roles="manager-gui"/>
Note that for Tomcat 7 onwards, the roles required to use the manager application were changed from the single manager role to the following four roles. You will need to assign the role(s) required for the functionality you wish to access.
manager-gui - allows access to the HTML GUI and the status pages
manager-script - allows access to the text interface and the status pages
manager-jmx - allows access to the JMX proxy and the status pages
manager-status - allows access to the status pages only
The HTML interface is protected against CSRF but the text and JMX interfaces are not. To maintain the CSRF protection:
Users with the manager-gui role should not be granted either the manager-script or manager-jmx roles.
If the text or jmx interfaces are accessed through a browser (e.g. for testing since these interfaces are intended for tools not humans) then the browser must be closed afterwards to terminate the session.
For more information - please see the Manager App HOW-TO.

tomcatのWebアプリケーションマネージャは、webapps/managerにはじめから居る

ただし、デフォルトでは、context.xmlで127.0.0.1以外は拒否られてる

そんで、conf/tomcat-users.xmlに、manager-guiロールを付与して、管理者名とパスワードを設定せんとあかん。

せ7> pwd
/usr/local/tomcat8/webapps/manager/META-INF
せ7> diff context.xml.org context.xml
20c20
<          allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
---
>          allow="127.0.0.1|192.168.2.*" />

せ7> pwd
/usr/local/tomcat8/conf
せ7> diff tomcat-users.xml.org tomcat-users.xml
43a44,46
> <role rolename="manager-gui"/>
> <user username="admin" password="admin" roles="manager-gui"/>

・ブラウザから下記にアクセス

http://192.168.2.7:8080/manager/html

 

■jdkツール

・jConsole

jmap

・jstat

・その他

https://docs.oracle.com/javase/jp/8/docs/technotes/tools/index.html

※何を調べるためにどんなツールが必要か

ミドルウェアの状態確認と性能評価およびチューニング

  • jvmのメモリオブジェクトのリアルタイム確認
  • jvmのメモリオブジェクトの統計情報取得
  • jvmのメモリ以外のリソース(ディスクIO、ネットワーク、cpu時間、プロセス間通信、ファイルディスクリプタ)のリアルタイム確認
  • jvmのメモリ以外のリソースの統計情報取得
  • ロードされているクラスの衝突の有無

 

 

 

■tomcat8の起動スクリプト

・bin/startup.sh

・bin/catalina.sh

 

■tomcat8起動スクリプト:bin/catalina.sh内でsourceされるスクリプト

・setenv.sh

・setclasspath.sh

※JAVA_HOMEなど

 

■Javaクラスローダー

https://ja.wikipedia.org/wiki/Javaクラスローダー

・JavaクラスローダーはJava仮想マシンの一部

・JavaクラスをJava仮想マシンに動的にロードする役割をもつ

・Javaの実行系は、クラスローダーがあるおかげでファイルやファイルシステムについて知る必要がない。Java 言語ではライブラリはJarファイルに格納され、様々なオブジェクトを格納することができる。クラスはコードに名前をつけた一つの単位であり、クラスローダはライブラリを見つけて内容をロードし、ライブラリに含まれるクラスをロードする責務を持つ。

・Javaクラスローダはツリー構造をしており、関連する親クラスローダを1つ所有している。

・JVMが開始されると、3つのクラスローダーが使用される

  • ブートストラップクラスローダー
  • 拡張クラスローダー
  • システムクラスローダー

・ブートストラップクラスローダーは、中核のJavaライブラリをロードする。(<JAVA_HOME>/lib ディレクトリ)。このクラスローダーはJavaVMの中心部分であり、ネイティブコードで記述されている。
・拡張クラスローダーは、拡張ディレクトリ(<JAVA_HOME>/lib/ext や、java.ext.dirsプロパティで指定された他のディレクトリ)にあるコードをロードする。これは、sun.misc.Launcher$ExtClassLoader クラスで実装されている。
・システムクラスローダーは、java.class.path 、すなわちシステムCLASSPATH 変数にあるクラスをロードする。こちらは、sun.misc.Launcher$AppClassLoader クラスで実装されている。

・ユーザー定義のクラスローダーは全てシステムクラスローダーからロードされるが、ユーザーが定義したClassLoaderに置き換えたり、さらにクラスローダの連結構造もユーザー定義することができる。これにより、下例のようなことが可能になる

  • クラスのロード・アンロードを動的に(たとえば、HTTPから)行う。
  • この用途は、
    • スクリプト言語の実装
    • ビーンビルダを用いて、
    • ユーザーが拡張の仕組みを定義する
    • 複数の名前空間が交わることを可能にする。これは、CORBA / RMIの基礎となっている。
  • バイトコードがロードされる方法を変える(たとえば、暗号化されたJavaクラスをロードする)。
  • ロード済みのバイトコードを改変する(たとえば、アスペクト指向プログラミングで用いれば、ロード時の織り込み)。

・JavaEEのアプリケーションサーバーは、通例サーバーに配置されたWARやEARアーカイブを階層的に配置されたクラスローダーでロードして、アプリケーション同士を隔離している。 いわゆる"サーブレットコンテナ"は、通例複数のクラスローダーを用いて実装されている。

Tomcatのようなコンテナでは、複数のクラスローダに階層関係を持たせることで、個々のクラス(ライブラリ)の独立性を保証している。Tomcatのクラスローダは、ロードしたクラスを管理し、Java仮想マシンは1つ以上のクラスローダを介して、クラス群の呼び出しを行う。

あるクラスローダがクラスをロードしようとしたときは、必ず親(祖先)のクラスローダによってすでにロードされているクラスが存在しないか確認する。そして、該当するクラスが存在しない場合のみ、自身でロードを行う。並列関係にあるクラスローダ同士は、まったく独立の関係にあり、たとえ同じクラスがロードされたとしても、一切関与しない。コンテナに対して、クラスライブラリを追加導入する場合、このクラスローダの階層関係と有効範囲を知っておくことは、ライブラリの競合による不具合を未然に防ぐために重要な知識である。

・JAR地獄

  • 同じライブラリの2つのバージョンが同時に利用可能になってしまい想定してない方のバージョンがロードされて不具合が起こる事象
  • アプリケーションAとAが使ってるライブラリBがどちらもライブラリCを要求してて、かつAとBに必要なCのバージョンが異なる場合に起こる競合
  • 上記のケースはフラットなクラスローダの場合より、複数のネストされたクラスローダによってロードされたクラスどうしに混入しやすく、発見しづらい。

 

■デーモンを起動する一般的な手法

tomcatはじめの2歩

 

■bootstrap.jar

Tomcat5 サーブレット/JSP コンテナ

Java 2 (つまり JDK 1.2 以降) 環境では、 クラスローダは親子関係のツリーとして構成されています。通常、 クラスローダが個々のクラスやリソースのロードの要求を受けると、 まずは要求を親のクラスローダに委譲し、 親のクラスローダ(複数の場合あり)が要求されたクラスやリソースを見つけられなかった場合だけ自分のリポジトリを見に行きます。 以下で説明するようにこれとは若干異なりますが、 Webアプリケーション用クラスローダのモデルも基本原則は同じです。

Tomcat 5 を起動すると、 以下のような親子関係に編成された一連のクラスローダを生成します。 以下の図では、親のクラスローダが子のクラスローダの上に表記されています。

【クラスローダの定義】

上の図で示した通り Tomcat 5 は、 以下のクラスローダを初期化の際に生成します。

  • Bootstrap - このクラスローダには Java 仮想マシン (JVM) が提供する基本ランタイムクラスと、加えてシステム拡張ディレクトリ ($JAVA_HOME/jre/lib/ext) のすべてのクラスが含まれています。 注意 - JVM によっては2つ以上のクラスローダとして実装されている場合もありますし、 (クラスローダとして)まったく参照できない場合もあります。
  • System - このクラスローダは通常、CLASSPATH 環境変数の内容を元に初期化されます。こうしたクラスは Tomcat 内部クラスからも、 Webアプリケーションからも参照できます。しかし、標準の Tomcat 5 起動スクリプト ($CATALINA_HOME/bin/catalina.sh または %CATALINA_HOME%\bin\catalina.bat) では、 CLASSPATH 環境変数そのものの内容を完全に無視し、 代わりに以下のリポジトリから System クラスローダを構築します。
    • $CATALINA_HOME/bin/bootstrap.jar - Tomcat 5 サーバを初期化するのに使う main() メソッドと、 サーバが依存するクラスローダ実装クラスが含まれます。
    • $JAVA_HOME/lib/tools.jar - JSP ページを Servlet クラスに変換する "javac" コンパイラが入っています。
    • $CATALINA_HOME/bin/commons-logging-api.jar - Jakarta Commons Logging の API。
    • $CATALINA_HOME/bin/commons-daemon.jar - Jakarta Commons Daemon の API。
  • Common - このクラスローダには、Tomcat 内部クラスからも、 すべての Webアプリケーションからも参照可能になっている追加クラスが含まれます。 アプリケーションクラスは、 通常はここに置くべきではありません。 $CATALINA_HOME/common/classes にある アーカイブされていないクラスやリソースのすべて、それに $CATALINA_HOME/commons/endorsed や $CATALINA_HOME/common/libにある JAR ファイル内のクラスやリソースのすべてをこのクラスローダから参照できます。 デフォルトでは以下のものが含まれます。
    • ant.jar - Apache Ant。
    • commons-collection.jar - Jakarta Commons Collection。
    • commons-dbcp.jar - Jakarta Commons DBCP。JDBC コネクションプールを Webアプリケーションに提供します。
    • commons-el.jar - Jakarta Commons EL。Jasper で使う EL (Expression Language) を実装します。
    • commons-pool.jar - Jakarta Commons Pool。
    • jasper-compiler.jar - JSP 2.0 コンパイラ
    • jasper-runtime.jar - JSP 2.0 ランタイム。
    • jmx.jar - JMX 1.2 実装。
    • jsp-api.jar - JSP 2.0 API。
    • naming-common.jar - Tomcat 5 で使われる JNDI 実装。 メモリ上のネーミングコンテキストに相当します。
    • naming-factory.jar - The JNDI Tomcat 5 で使われる JNDI 実装。 エンタープライズリソース (EJBやコネクションプール) への参照を解決します。
    • naming-resources.jar - 特殊な JNDI ネーミングコンテキスト実装。 Webアプリケーションの静的リソースに相当するものとして使われます。
    • servlet-api.jar - Servlet と JSP の API クラス。
    • xerces.jar - XML パーサ。Tomcat 内部クラスと Webアプリケーションから参照可能です。
  • Catalina - このクラスローダーは初期化時に、Tomcat 5 そのものを実装するのに必要なクラスやリソースすべてを含みます。 これらのクラスやリソースは Web アプリケーションからまったく参照できません。 $CATALINA_HOME/server/classes にあるアーカイブされないクラスやリソースすべて、 それに $CATALINA_HOME/server/lib にある JAR ファイル内のクラスやリソースがこのクラスローダで参照可能となります。 デフォルトでは以下のものが含まれます。
    • catalina.jar - Tomcat 5 の Catalina Servlet コンテナの部分の実装。
    • jakarta-regexp-X.Y.jar - 正規表現処理ライブラリである Jakarta Regexp のバイナリ配布。リクエストフィルタの実装で使われています。
    • servlets-xxxxx.jar - Tomcat の機能の一部として提供される内部 Servlet のそれぞれに関連するクラス。 対応するサービスが不要な場合に完全に削除できるように、 またセキュリティマネージャの特別な許可の対象にできるように、 これらは別々になっています。
    • tomcat-coyote.jar - Tomcat 5 の Coyote コネクタ。
    • tomcat-http11.jar - スタンドアロンの Java HTTP/1.1 コネクタ。
    • tomcat-jk2.jar - JK 2 Web サーバコネクタの Java の部分のクラス。 ApacheやiPlanet の iAS と iWSといった Web サーバの背後で Tomcat を実行できるようにします。
    • tomcat-util.jar - Tomcat コネクタの一部で必要なユーティリティクラス。
  • Shared - このクラスローダは、すべての Webアプリケーションを通して共有したいクラスやリソースを配置する場所です (Tomcat 内部クラスでもアクセスが必要な場合のみ例外で、 代わりに Common クラスローダに配置すべきです)。 $CATALINA_HOME/shared/classes 上のアーカイブされないクラスやリソースすべて、 それに $CATALINA_HOME/shared/lib にある JAR ファイル内のクラスやリソースがこのクラスローダで参照可能になります。 $CATALINA_BASE 環境変数を使って同じバイナリから複数の Tomcat インスタンスを実行する場合のこのクラスローダのリポジトリは、 $CATALINA_HOME ではなく $CATALINA_BASE を基準とします。
  • WebappX - 単一の Tomcat 5 インスタンスに配備された Webアプリケーションごとにクラスローダが1つずつ生成されます。 Webアプリケーションの配置場所の /WEB-INF/classes ディレクトリにあるアーカイブされないクラスやリソースすべて、 加えて Webアプリケーションの配置場所の /WEB-INF/lib にある JAR ファイル内のクラスやリソースは、これらを含んでいる Webアプリケーションから参照可能ですが、 他の Webアプリケーションからは参照できません。

上で説明した通り、Webアプリケーションクラスローダは、 デフォルトの Java 2 委譲モデルとは異なっています (これは Servlet 仕様バージョン 2.3 の 9.6 節での勧告に基づくものです)。Webアプリケーションの WebappX クラスローダからのクラスのロード要求が処理される際、 このクラスローダは最初に委譲を行なわずに、 ローカルのリポジトリをチェックします。ただし例外があり、 JRE の基本クラスに属するクラスはオーバーライドできません。(JDK 1.4 以降の XML パーサコンポーネントなど) いくつかのクラスについては、JDK 1.4 の Endorsed 機能が適用可能です (詳細については上の Common クラスローダ定義をご覧下さい)。それに加えて、以下のクラスパターンでは、 クラスローダは常に最初に委譲を行ないます (さらに親のクラスローダがロードしないクラスは自らロードを行ないます)。

  • javax.*
  • org.xml.sax.*
  • org.w3c.dom.*
  • org.apache.xerces.*
  • org.apache.xalan.*

最後に、Servlet API のクラスを含む JAR ファイルすべてをこのクラスローダは無視します。 Tomcat 5 の他のクラスローダはすべて通常の委譲パターンにしたがいます。

 

したがって、クラスやリソースのロードの際のリポジトリのチェックは、 Webアプリケーションから見ると以下の順序になります。

  • JVM のブートストラップクラス
  • System クラスローダの各クラス (上述)
  • Webアプリケーションの /WEB-INF/classes
  • Webアプリケーションの /WEB-INF/lib/*.jar
  • $CATALINA_HOME/common/classes
  • $CATALINA_HOME/common/endorsed/*.jar
  • $CATALINA_HOME/common/lib/*.jar
  • $CATALINA_HOME/shared/classes
  • $CATALINA_HOME/shared/lib/*.jar

 

■CATALINA_TMPDIR

以下は、catalina.shの注釈から抜粋

せ7> cat /usr/local/tomcat8/bin/catalina.sh

・・・前略・・・

#   CATALINA_TMPDIR (Optional) Directory path location of temporary directory
#                   the JVM should use (java.io.tmpdir).  Defaults to
#                   $CATALINA_BASE/temp.

・・・中略・・・

if [ -z "$CATALINA_TMPDIR" ] ; then
  # Define the java.io.tmpdir to use for Catalina
  CATALINA_TMPDIR="$CATALINA_BASE"/temp
fi

・・・後略・・・

 

■tomcatのファイル構造

tomcatはじめの2歩