アーカイブ

Archive for 2011年9月

JBoss AS 7 Getting Started Guide – 2

今回は Getting Started Guide (※ 以降スタードガイド)の後半部分に記載されている管理(Managing your JBoss Application Server 7)について意訳&解説します。

JBoss AS7 管理 

AS7 は稼働中のインスタンス管理に以下の2つの仕組みを提供します。

  • web ベースの管理コンソール
  • コマンドラインインターフェース(CLI)

上記の管理 UI とは別に 2 種類の管理用 I/F (Native I/F, HTTP I/F)が提供せれており、管理 UI もこれらの I/F 経由で AS7 へアクセスします。管理用 I/F は独自のスクリプト等外部のプログラムからのアクセスが可能です。

管理用 I/F についての詳細は Admin Guide (管理ガイド) – Management Clients (管理クライアント) を参照して下さい。

管理コンソール 

管理コンソールへはブラウザを使用して以下のURLにアクセスします。

http://localhost:9990/console

Note: 9990 番ポートが管理コンソールのデフォルトとして設定されています。デフォルトポートを変更する場合、 設定ファイルの http-interface 要素の port 属性を変更します。

<management-interfaces>

<native-interface interface=”managementport=”9999” />

<http-interface interface=”managementport=”9990“/>

</management-interfaces>

上記の設定ファイルは standalone.xml または host.xml になります。上記の設定では、管理用 I/F である Native I/F と HTTP I/F に対して interfaceport の設定を行っています。

デフォルトの standalone.xml で確認してみると、management という名前で宣言された interface を参照していることが分ります。

<interfaces>

<interface name=”management“>

<inet-address value=”127.0.0.1″/>

</interface>

<interface name=”public“>

<inet-address value=”127.0.0.1″/>

</interface>

</interfaces>

スタートガイドには http-interface の port を変更した場合、ウェルカムページのリンクから管理コンソールにアクセスできなくなると書かれていますが、アクセスできるようです。

8080 ポートの /console にアクセス(ウェルカムページの “Administration Console” リンクは 8080/console へのアンカータグです。)すると http-interface が設定されたポートの /console にリダイレクトされます。

コマンドラインインターフェス(CLI)

コマンドラインからの管理作業もしくはバッチ処理を行う場合、 $JBOSS_HOME/bin/jboss-admin.sh (以降、管理スクリプトと呼称) を使用します。管理スクリプトは管理コンソールと同等の機能を提供します。

$ cd $JBOSS_HOME/bin
$ ./jboss-admin.sh –connect 
Connected to standalone controller at localhost:9999

管理スクリプトの connect コマンドのパラメータにホスト/ポートを指定しない場合、 localhost:9999 がデフォルトとして使用されます。

管理スクリプトを使用すれば、リソースの追加、変更、削除やアプリケーションのデプロイ/アンデプロイが可能です。

管理スクリプトのコマンド/コマンドシンタックスについてはサーバに接続後(connect コマンド成功後) “help” を実行して下さい。

アプリケーションを AS7 にデプロイする 5 つの方法についての 紹介ビデオ <http://vimeo.com/25831010> をチェックしてみて下さい。

管理スクリプトについては 前回のエントリ AS7 停止方法の解説で少しふれました。

管理スクリプトの詳細は  Admin Guide (管理ガイド) – Management Clients (管理クライアント)  や Admin Guide (管理ガイド)- Core management concepts (コア管理コンセプト) に記載されています。

管理スクリプトには コマンド、オペレーション、リソース、アドレス といった概念が登場します。

簡単に言ってしまえば、 XML 設定ファイル(standalone.xml, host.xml, domain.xml)の木構造をコマンドを使用して辿って値の照会、編集、削除を行うという感じなんですが。

管理コンソールは AS7 インスタンスとネイティブプロトコルを使用して通信します。このネイティブプロトコルは前節でちょっと登場した native-interface で指定したポート番号を使用します。

せっかくなので、 native-interface のポート番号を変更して管理スクリプトから接続できることを確認してみましょう!

  1. $JBOSS_HOME/standalone/configuration/standalone.xml の native-interface 要素 の port 属性を 9991 等に変更する。
  2. AS7 を起動($JBOSS_HOME/bin/standalone.sh)する。
  3. 管理スクリプトを起動($JBOSS_HOME/bin/jboss-admin.sh)する。
  4. “connect localhost:9991” コマンドを実行する。
  5. “help” や “:read-operation-names” 等を実行して遊んでみる。
  6. “quit” を実行してさようなら。。。

どうでしょう?うまくいったでしょうか?

サンプルデータソースの設定

前回のリリース(AS6)と同様に開発用組込み DB のデータソースとして ExampleDS が設定されています。データソースを設定するには以下 2 つの方法があります。

  1. モジュール
  2. デプロイメント

初期状態の ExampleDS データソースはモジュールとして設定されています。このモジュールは $JBOSS_HOME/modules/com/h2database/h2 に格納されています。

ExampleDS の設定は以下の通りになります。

<subsystem xmlns=”urn:jboss:domain:datasources:1.0″>

<datasources>

<datasource jndi-name=”java:jboss/datasources/ExampleDS” pool-name=”ExampleDS“>

<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>

<driver>h2</driver>

<pool>

<min-pool-size>10</min-pool-size>

<max-pool-size>20</max-pool-size>

<prefill>true</prefill>

</pool>

<security>

<user-name>sa</user-name>

<password>sa</password>

</security>

</datasource>

<xa-datasource jndi-name=”java:jboss/datasources/ExampleXADS” pool-name=”ExampleXADS”>

<driver>h2</driver>

<xa-datasource-property name=”URL”>jdbc:h2:mem:test</xa-datasource-property>

<xa-pool>

<min-pool-size>10</min-pool-size>

<max-pool-size>20</max-pool-size>

<prefill>true</prefill>

</xa-pool>

<security>

<user-name>sa</user-name>

<password>sa</password>

</security>

</xa-datasource>

<drivers>

<driver name=”h2module=”com.h2database.h2“>

<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>

</driver>

</drivers>

</datasources>

</subsystem>

データソース subsystem は IronJacamar プロジェクトが提供しています。データソース設定に関する詳細については IronJacamar プロジェクトのドキュメントを参照して下さい。

まずは、モジュール/デプロイメントについて補足します。

簡単に言うと、

モジュール  –> モジュールとして認識($JBOSS_HOME/modules に module.xml と jar ファイルを配置)された JDBC ドライバを使用する。

デプロイメント  –> JDBC の jar ファイルを直接デプロイする。

という感じになります。詳細は Admin Guide (管理ガイド) – DataSouce Configuration (データソース設定) に書かれていますので、今後解説します。

データソース subsystem は standalone.xml, domain.xml で設定されています。設定ファイルが一元管理されているのは分りやすくて素晴らしいですな。

IronJacamar は JCA の実装になります。 JCA って何かって? JSR 322: JavaTM EE Connector Architecture 1.6 です。要は DB, ERP, MOM 等の外部リソース(EIS的な!)と接続するためのコネクタの仕様です。

個人的には IronJacamar について Deep Dive して妙なコネクタ作ってみたい気もするのですが。。。

データソースは 管理コンソールもしくは管理スクリプト から管理が可能ですので、ぜひツールを使ってみましょう。

管理スクリプトを使用して “/subsystem=datasources:read-resource(recursive=true)” や “/subsystem=datasources:installed-drivers-list” を実行すると面白い結果が表示されるので試してみて下さい。

ロギングの設定

AS7 のログイング設定は XML 設定ファイルもしくはログマネージャ設定ファイルにより可能です。デフォルトのロギング設定には $JBOSS_HOME/$PROFILE/configuration/logging.properties が使用されています。

※ $PROFILE は standalone / domain を表します。

logging.properties で設定されているデフォルト設定は一般的な要件を十分に満たしています。

カスタムロギングカテゴリが必要な場合、 standalone.xml, domain.xml に設定されている項目をカスタマイズします。

XML 設定

XML によるロギング設定は standalone.xml, domain.xml ファイルの logging subsystem 要素(およびその子要素)に対して行います。

これはカスタムロギングカテゴリを設定するのに推奨される方法です。

ロギング設定には以下 7 つの主要な要素があります。

  1. <root-logger />
  2. <logger category=”” />
  3. <console-handler />
  4. <file-handler />
  5. <periodic-rotating-file-handler />
  6. <size-rotating-file-handler />
  7. <async-handler />

root-logger にはデフォルトとして他のロガーに継承されるベースとなる値を設定します。

XML によるロギング設定の詳細なオプションを知るためには、 $JBOSS_HOME/docs/schema/jboss-as-logging_x_x.xsd のの XML スキーマを参照して下さい。

※ スタートガイドには $JBOSS_HOME/docs/schema/jboss-logging.xsd と記載されていますが、 バージョン 7.0.1 で確認したところ jboss-as-logging_1_1.xsd が該当するようです。

ロギング設定に関する詳細は Admin Guide (管理ガイド) – Logging configuration (ロギング設定) を参照して下さい。 

次の例は、 “org.jboss.as.quickstart.kitchensink” カテゴリでデバッグレベルのロガーの設定を行っています。

<logger category=”org.jboss.as.quickstart.kitchensink” >

<level name=”DEBUG“/>

</logger>

上記の例のロガーは <root-logger /> からハンドラを継承しています。この設定は <logger /> タグの use-parent-handlers 属性に false を設定することにより上書き可能です。

この方式の有利な点は、レベルを管理コンソールから観点に変更可能なことです。これによりアプリケーションサーバの再起動無しにデバッグレベルの変更が可能です。

ログマネージャ設定

ログマネージャの設定ファイルは $JBOSS_HOME/$PROFILE/logging.properties になります。

※ $PROFILE は standalone / domain を表します。

logging.properties で指定可能なプロパティは次の通りになります。

Logger options
  • loggers=<category>[,<category>,…]  – カテゴリをカンマ区切りで指定します。ここで指定されていないカテゴリについて以降のプロパティを設定することはできません。
  • logger.<category>.level=<level> – カテゴリのログ出力レベルを指定します。 JDK のログ出力レベル(SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST)、 JBoss Logging の 3 つのスタイルのログ出力レベル(FATAL, ERROR, WARN, INFO, DEBUG, TRACE)または特殊なログ出力レベル(OFF, ALL)が指定可能です。
  • logger.<category>.handlers=<handler>[,<handler>,…] – このロガーに適用するハンドラ名をカンマ区切りで指定します。ハンドラは同一のプロパティファイルで設定する必要があります。
  • logger.<category>.filter=<filter> – カテゴリに対するフィルタを指定します。フィルタは同一のプロパティファイルで設定する必要があります。
  • logger.<category>.useParentHandlers=(true/false) – 親のロガーにログ出力を伝播されるかどうかを true/false で指定します。
Handler Option
  • handler.<name>=<className> – (必須項目)ハンドラのクラス名を指定します。
  • handler.<name>.level=<level> – このハンドラのログ出力レベルを指定します。出力レベルを指定しない場合、デフォルト値である ALL が適用されます。
  • handler.<name>.encoding=<encoding> – 文字エンコーディングを指定します。指定された文字エンコーディングがハンドラによりサポートされない場合、ハンドラ固有のデフォルト文字エンコーディングが適用されます。
  • handler.<name>.errorManager=<name> – エラーマネージャ名を指定します。エラーマネージャは同一のプロパティファイルで設定する必要があります。指定しない場合、ハンドラにエラーマネージャは適用されません。
  • handler.<name>.filter=<name> – フィルタ名を指定します。フィルタは同一のプロパティファイルで設定する必要があります。指定しない場合、メッセージはフィルタリングされません。
  • handler.<name>.formatter=<name> – フォーマッタ名を指定します。フォーマッタは同一のプロパティファイルで設定する必要があります。フォーマッタを指定しない場合、大半のハンドラはログ出力を行いません。
  • handler.<name>.properties=<property>[,<property>,…] – JavaBean スタイルのプロパティをカンマ区切りで指定します。
  • handler.<name>.<property>=<value> –  key : value 型プロパティの設定を行います。
Error manager options
  • errorManager.<name>=<className> – (必須項目)エラーマネージャのクラス名を指定します。
  • errorManager.<name>.properties=<property>[,<property>,…] – JavaBean スタイルのプロパティをカンマ区切りで指定します。
  • errorManager.<name>.<property>=<value> – key : value 型プロパティの設定を行います。
Formatter options
  • formatter.<name>=<className> – (必須項目)フォーマッタのクラス名を指定します。
  • formatter.<name>.properties=<property>[,<property>,…] – JavaBean スタイルのプロパティをカンマ区切りで指定します。
  • formatter.<name>.<property>=<value> – key : value 型プロパティの設定を行います。
Filter options
  • filter.<name>=<className> – (必須項目)フィルタのクラス名を指定します。
  • filter.<name>.properties=<property>[,<property>,…] – JavaBean スタイルのプロパティをカンマ区切りで指定します。
  • filter.<name>.<property>=<value> – key : value 型プロパティの設定を行います。

ログマネージャについて解説します。このモジュールの正式名称は JBoss Log Manager (※ 以降 logmanager ) になります。

JIRA はこちら<https://issues.jboss.org/browse/LOGMGR#selectedTab=com.atlassian.jira.plugin.system.project%3Asummary-panel>!

logmanager は module として動作し $JBOSS_HOME/modules//org/jboss/logmanager/main/jboss-logmanager-1.2.0.GA.jar にクラスファイルが配置されています。

logmanager のソースコードは <http://source.jboss.org/browse/JBossCommon/jboss-logmanager> で参照可能です。

logmanager クラス構成や使い方は JavaTM 2 プラットフォームのコアロギング機能(詳細は JavaTM Logging Overview あるいは  java.util.loggin API Document を参照して下さい。) のそれを拡張したものとなっています。$JBOSS_HOME/$PROFILE/configuration/logging.properties, $JBOSS_HOME/domain/configuration/logging.properties で確認できるデフォルトのコンソールハンドラ実装の org.jboss.logmanager.handlers.ConsoleHandler は java.util.logging.Handler を継承しており、他の主要クラスも java.util.logging の主要クラスを継承しています。

※ $PROFILE は standalone / domain を表します。

なので、ログマネージャの設定でつまずくことはあまりないと思います。

ログファイルである boot.log と server.log の違いについて補足します。

boot.log には logging.properties の設定に従い AS7 の起動時にログサービス(ブートストラップログハンドラ等)が起動するまでのログが出力されます。

server.log には standalone.xml または domain.xml の logging subsystem 設定に従い ログサービス起動以降のログが出力されます。

通常はアプリケーションのロギングの要件に従い sdandalone.xml または domain.xml を使用してカテゴリやフォーマッタ等のカスタマイズを行います。

次回からはいよいよ Admin Guide (管理ガイド)の意訳&解説を開始します!

タグ: ,

JBoss AS 7 Getting Started Guide – 1

今回から 2 回に分けて Getting Started Guide(※ 以降スタートガイド)の解説を行います。
スタートガイドのインデックスはこんな感じ。

– ダウンロード
– 動作条件
– インストール
– AS 7 – Quick Tour
– ディレクトリ構造
– 設定
– 起動
– 特定の設定ファイルを使用した AS7 の起動
– 管理
– サンプル DataSource の修正
– AS 7 ドキュメント構成

インデックスを見て分かる通り、とりあえずダウンロードして動かすのと概要を知るためのドキュメントになっています。
個々の機能の詳細については Admin Guide(管理ガイド) で解説されています。

では、はじめましょう!

Getting Started with JBoss Application Server 7

AS7 は JBoss Application Server シリーズの最新のリリースです。 AS7 は高速でパワフルな Java EE 6 仕様の実装です。

MSC (Modular Service Container) 上に構築された最先端のアーキテクチャにより AS7 の各々のサービスはアプリケーションが必要とするタイミング(オンデマンド)で稼働します。

AS7 (7.0.0.Final) は Java EE 6 Web Profile に準拠しています。下記の表は Java EE 6 に含まれる仕様と AS7 で提供されるものの対応関係を表します。

JBossAS7-JavaEE

この表で重要なのが、

  •  AS7 は現在のところ Java EE 6 Full Profile の認定は受けていない。
  • Full Profile 版の Enterprise JavaBeans 3.1 対応状況は Lite である。

でしょうか。

後者について少し補足します。 EJB 3.1 Lite は EJB 3.1 のサブセットです。

一般的な Web アプリケーションが最大公約数的に使用するであろう EJB の機能を集めたサブセットになります。 要は EJB からあまり使われないと思われる機能をとっぱらったサブセットですね。

SLSB/SFSB, CMT/BMT, インターセプター や EJB 3.1 の新機能である シングルトン、インターフェース不要のコンポーネント宣言 は可能ですが、リモートインターフェース、 JAX-WS 、 EJB タイマー、非同期 Session Bean、 MDB 等が使用できません。

Java EE 6 (Lite)の詳細は JSR 318: Enterprise JavaBeansTM 3.1 を参照して下さい。

ダウンロード

JBoss Application Server 7 の配布物は JBoss Application Server Doanload Site から取得可能です。

AS7 のインストールバイナリには、 Full Profile / Web Profile の二つのバージョンがあります。2011/09/12 現在の最新バージョンは、 7.0.1.Final になります。AS7 のバイナリアーカイブは zip / tar 形式で配布されているので、好きな形式の Full Profile バージョンをダウンロードして使用します。

動作必要条件

JDK6 以降が必要です。

JDK7 でも動く!と書いてありますが、無理に使う必要はありません。AS7 を動かすのに必要なのはこれだけです。

インストール

ダウンロードしたアーカイブを $HOME/java/as/7.0.1 等分かりやすいディレクトリに展開しましょう。
あと、環境変数 JAVA_HOME を設定しておくといい感じです。

ちなみに僕の環境はこんな感じ。

JAVA_HOME -> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JBOSS_HOME  -> /Users/yoshikazu/java/as/7.0.1 ※ JBOSS_HOME という環境変数は不要です。

windows 環境であれば、$HOME/java/jdk/1.6.0_26 $HOME/java/as/7.0.1 等を設定するとシンプルでいい感じかもしれません。

そうそう、バックアップを取らないと気が済まない!というような人は $JBOSS_HOME/bin, $JBOSS_HOME/domain, $JBOSS_HOME/standalone をバックアップしておきましょう。
これ以外にも色々用意周到にカスタマイズした方がいいところはあるのですが、その辺の話は追々します。

AS7 クイックツアー

$JBOSS_HOME ディレクトリ構成

ディレクトリ

概要

bin

起動スクリプト、起動設定ファイルが格納されています。

bundles

OSGiバンドル ※ OSGi については 前回のエントリ で簡単に紹介しているので参照して下さい。

docs/schema

設定ファイルのXMLスキーマが格納されています。

domain

ドメインモードで起動した場合に使用する設定ファイル、アプリケーションのデプロイメント

modules

AS7 ではモジュールベースのクラスローディングアーキテクチャが採用されています。AS7 およびデプロイされるアプリケーションにより使用される各種モジュールが格納されています。

standalone

スタンドアロンモードで起動した場合に使用する設定ファイル、アプリケーションのデプロイメントを配置します。

welcome-content 

デフォルトのウェルカムページコンテンツが格納されています。

これまでのバージョンから大きく変更されて(まぁ大幅に変更されてあまりこれまでの姿をとどめてはいませんが。。。)ますね。特に重要なのが、 bin, domain, modules, standalone です。

modules についてはモジュールの概念や制御方法の説明と合わせ今後紹介します。

$JBOSS_HOME ディレクトリには jboss-modules.jar が配置されています。これは Modular Service Container(MSC)コアであり、軌道スクリプトから呼び出される main メソッドを含む AS 起動のエントリポイントとなります。

$JBOSS_HOME/standalone ディレクトリ構成

standalone モードで複数の JBoss インスタンスを起動した場合、(これまでのバージョンの JBoss AS と同様に)各々は独立した java プロセスとなります。

standalone 構成に関する 設定ファイル、デプロイディレクトリ、AS インスタンスが使用する書込みエリア 等は standalone ディレクトリのサブディレクトリに格納されます。

これまでのバージョンの JBoss AS 実現していた機能(クラスタ含む)は standalone モードでも実現されています。

ディレクトリ 概要 
configuration standalone 構成の AS に関する設定ファイル( AS7 では設定ファイルが一元化されています。)が含まれます。
data  永続化データ(HSQLDB、トランザクションログ)が配置されます。
deployments
ファイルシステムベースのデプロイメント(オートデプロイ可能)ディレクトリです。
フェイルシステムベースのデプロイスキャンは開発時のみの使用が推奨され、プロダクション環境でのデプロイにはサーバ管理 API の使用が推奨されます。
lib/ext  Extension-Listメカニズム(Java拡張機能機構)を使用したアプリケーションから使用されるライブラリを配置します。
log ログ(server.log、boot.log)ファイルが配置されます。
tmp  一時ファイル(アーカイブ形式でデプロイしたアプリケーションの展開ディレクトリ)およびコンパイル済 JSP (tmp/work)等が配置されます。

上述のサブディレクトリは JBoss のこれまでのバージョンのディレクトリ構成に通ずるところがあります。

data, log, tmp についてはこれまでのバージョンの同名のディレクトリと同様です。

重要な変更点として、 configuration ディレクトリに設定が集約され一元管理が可能になったという点とデプロイディレクトリ名が deploy => deployments になったということです。

また、これまでバージョンの JBoss AS の deploy ディレクトリには、管理コンソールの war 、デフォルト DataSource の設定ファイルや AS の機能として動作する MBean を sar 形式で配置していたのですが、そういった AS 自身が使用するものは deployments に配置されていません。

なのでデプロイディレクトリがすっきりした印象です。

デプロイには、Auto, Manual, (展開形式デプロイを使用した場合の)ファイル変更トリガーによる再デプロイ の 3 つのモードがあります。これらはデプロイメントスキャナの設定により指定可能です。

このメカニズム自体はこれまでのバージョンにおけるスキャナから大きな変更はありませんが、 AS7 のデプロイメントスキャナはデプロイの状態を deployments ディレクトリへのマーカファイル( .failed 等)配置という形で表現します。

これらについては今後検証をしていきます。

$JBOSS_HOME/domain ディレクトリ構成

AS7 の(これまでの JBoss AS と比較して)主要な特徴は複数の AS インスタンス(server)の一元管理機能( ≒ domain)です。

そして、複数のインスタンス(server)の集合は domain として扱うことが可能です。

domain は host controller プロセスの管理下にあるホストマシン (物理OS/仮想OS)上で動く AS インスタンス(server) から構成されます。

host controller は AS インスタンスの起動/停止等のライフサイクル管理および( host controller )自身を管理する domain controller と相互に連携を行います。

domain 構成に関する 設定ファイル、デプロイメント、(広義の) domain プロセスが使用する書込みエリア等は domain ディレクトリのサブディレクトリに格納されます。

ディレクトリ 概要 
configuration domain, host controller, server( ≒ AS インスタンス)に関する設定ファイルを含みます。domain の管理下にある全ての server( ≒ AS インスタンス) に関する設定は configuration ディレクトリに格納(AS7 では設定ファイルが一元化されています。)されます。
content host controller のための内部的な作業エリアで、内部的にはデプロイメント(デプロイするアプリケーションそのもの)を格納します。エンドユーザが操作する機会はありません。※ domain モードはファイルスキャンによるデプロイをサポートしません。
lib/ext Extension-List メカニズム(Java 拡張機能機構)を使用したアプリケーションから使用されるライブラリを配置します。
log host controller プロセスが使用するログファイルおよび process controller(他の host controller プロセスや他の server プロセスを生成する軽量なプロセス)が使用するログファイルが格納されます。
servers
server インスタンスが使用する書込みエリアです。 各々の server インスタンスは初回起動時にそれぞれサブディレクトリを作成します。
それぞれの server のサブディレクトリには更に以下のサブディレクトリが存在します。
data — server が(server)自身が必要とする永続化データを書き込みます。
log — server が書き込むログファイルを格納します。
tmp — server によって書き込まれる一時ファイルを格納します。

AS7 では domain, host, server group, server, profile, subsystem という概念や host controller, domain controller, process controller といったプロセスが登場します。これらの概念をある程度クリアにしておかないと上記の説明は理解しにくいと思います。

現段階では、 domain 構成は複数の AS インスタンス( ≒ server )を一元管理するための仕組みで AS 自身のプロセス( ≒ server )以外にもなにやらいくつかの AS 管理用プロセスが起動されるみたいだぞと思っていれば OK かと思います。

AS7 設定(ファイル)

standalone 構成時の設定(ファイル)
standalone.xml(デフォルト)

Java EE6 Web Profile のサービス(機能)構成で起動する場合の設定ファイルです。

standalone-preview.xml

Java EE6 Full Profile のサービス(機能)構成で起動する場合の設定ファイルです。

standalone-ha.xml

デフォルトのサービス(機能)を使用しクラスタを構成する場合の設定ファイルです。

standalone-preview-ha.xml

Java EE6 Full Profile のサービス(機能)を使用しクラスタを構成する場合の設定ファイルです。

domain 構成時の設定(ファイル)
domain.xml(デフォルト)

Java EE6 Web Profile のサービス(機能)を使用し domain を構成する場合の設定ファイルです。

domain-preview.xml

Java EE6 Full Profile のサービス(機能)を使用し domain を構成する場合の設定ファイルです。

AS7 の起動時にどの設定ファイルを使用するかをパラメータとして指定します。設定ファイルの内容の詳細は今後解説します。

AS7 の起動

AS7 の起動には standalone, domain 各々のモードにおいて専用の起動スクリプトを使用します。以降では起動スクリプトおよびそのオプションを解説します。

standalone モードで起動する場合
$JBOSS_HOME/bin/standalone.sh

-D[=]  –> システムプロパティを指定します。

–server-config=  –> 設定ファイ名を指定します。※ デフォルトは standalone.xml となります。

domain モードで起動する場合

$JBOSS_HOME/bin/domaina.sh スクリプトを使用します。オプションは以下の通りです。

–backup  –> domain の永続化された設定のコピーを作成します。 ※当該 host が domain controller でない場合でも有効なオプションです。

–cached-dc  –> 当該 host が domain controllerでなく、domain controller にアクセスで きない場合、バックアップした domain 設定を使用して起動します。

–domain-config=   –> domain の設定ファイル名を指定します。 ※デフォルトは “domain.xml”となります。

–host-config=  –> host の設定ファイル名を指定します。 ※デフォルトは “host.xml”となります。

–pc-address=  –> process controllerソケットアドレスを指定します。

–pc-port=  –> process controller において server ソケットを登録するためのプロセス名を指定します。

–interprocess-name=  –> 当該 host controller のアドレスを指定します。

–interprocess-hc-address=  –> 当該 host controller のポートを指定します。

また、 domain モードでの JVM パラメータ(-Xmx, -Xms 等)は $JBOSS_HOME/bin/domain.conf で設定します。

特定の設定ファイルを使用した AS7 の起動

Java EE6 Full Profile で standalone モードで起動する場合

$JBOSS_HOME/bin/standalone.sh –server-config=standalone-preview.xml

Java EE6 Full Profile で domain モードで起動する場合

$JBOSS_HOME/bin/domain.sh –server-config=domain-preview.xmlr

AS7 の停止

AS7 (standalone, domain)をフォアグラウンドプロセスで起動した場合
[ Ctrl + C ]
管理スクリプト(CLI)を使用する場合
$JBOSS_HOME/bin/jboss-admin.sh –connect controller=<IP>:<PORT> command=:shutdown

<IP>  –> 停止対象の standalone インスタンスがバインドされたIP(デフォルトでは localhost となります)を指定します。

<PORT>  –> 停止対象の standalone インスタンスがバインドされたポート(デフォルトでは 9999 となります)を指定します。

起動確認

起動スクリプトを実行しコンソール(もしくは server.log )に ERROR ログが出力されず、以下のログが出力されることを確認しましょう。

23:17:50,318 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final “Zap” started in 2206ms – Started 93 of 148 services (55 services are passive or on-demand)

※ 僕の環境(MacBook Air 2011 mid)で起動した際のログです。

上述のログの出力を確認後、 に web ブラウザからアクセスし、以下のような AS7 のウェルカムページが表示されれば AS7 が正常に起動されているはずです。

AS7 Welcom Page

本エントリでは、スタートガイドの前半部分の意訳/補足を行いました。次回はスタートガイドの残り(管理概要、Example DataSource の修正 等)を解説します。

タグ: ,

Start with JBoss AS 7

OSS が好きで OSS に育てられ OSS でご飯を食べている技術者としてブログ書きたいなと思いつつも書かずに数年。。。

JBoss AS 7 の登場!いい機会なので技術的なことを書いていきます。

しばらくは AS7 や EE6 について書くことになりますが、他の言語やツール, F/W, M/W, アルゴリズム, Tips 等々興味のある主に OSS 関連技術や開発プロセスについても書いていきます。

始めるからには、定期的にコツコツとやっていくつもりではいますが、お腹が痛くなったり PC の調子が悪くなったり死んだじいちゃんの遺言により休まなきゃいけない日があるかもしれませんが、温かい目で見て下さい。

書く内容のレベルは、初心者からお年寄りまでをモットーに入門的な内容からマッドサイエンティスト的な内容まで書いていくつもりでいます。

そうそう、赤い帽子の会社で JBoss コンサルタントのお仕事をしていますが、僕個人は間違いの塊みたいなもんです。

内容におかしなところがある場合は優しくご指摘をお願いします。

それでは、 JBoss AS  7 いってみましょう!

JBoss AS 7 について、『6とは違うのだよ、6とは!』的な内容をてっとり早く知りたければ、あるいは準備体操という観点で JBoss AS 7 概要 を読んでみるのがいいかもしれません。

プロジェクトのトップページ JBoss AS 7 概要 に書いてあることを意訳すると次のような感じになります。

※ 意訳部分は こんな感じの書式 を使用してます。

無類のスピード!

ハンパない高速起動!

AS7 では起動プロセスの並列化による wait の削減やマルチコア CPU への対応を行っています。また、主要でないサービスは最初に使用されるまで稼働を遅延させます。

また、2回目以降の起動ではキャッシュ/インデックス化されたメタデータを使用し余分な起動時間が削られます。

ここで言うところの 主要でないサービス? や キャッシュ/インデックスって? については追々書いていきます。

これらの改善により AS7 はこれまでのバージョンより起動時間が10倍短縮されているとのことです。

10倍短縮ってどういうことなんでしょうね??? AS7 の起動時間を 1s とすると、その10倍は 10s 、つまり以前のバージョンは 11s ということでしょうか。

僕の環境(MacBook Pro Early 2011)だとピュアな状態の 7.0.1(standalone)の起動が 1.5s なのに対して、 5.1.0(default プロファイル) の起動が 18s 程度なのでまぁそんなもんですかね。

クイックターンアラウンド

高速化や柔軟なデプロイ構造による並列デプロイメントや静的リソースの編集等効率の良い開発が可能!

詳細は別途解説するとして、AS7 の性能/機能ではありませんが EJB lite(Web Profile) 等も相まって今後は EE も真の開発効率の向上が期待できます。

JSP や ManagedBean もしくは SFSB / JPA Entity 等々をちょっと変更しただけなのに、 EAR にビルドしてデプロイして。。。場合によっては AS を再起動して。。。アプリケーションがロードされるのをひたすら待つというのは精神衛生上非常によろしくないです。

これまで3分かかっていた作業が10秒に短縮されれば、これまで回避していた作業を頻繁に行うことになります。

これまで回避していた作業が何か。。。コードの小さな部分の検証や UI のデザイン変更等ですかね、これまでは検証に時間がかかるのである程度コーディングをためた状態で動作検証ということをしていたのですが、これだと一つ一つの事象に目がいき難くなるのとコーディングに対する妥協の入り込む隙が生まれてしまいます。まぁこれは僕の個人的な性格によるものかもしれませんが。。。

コードの小さい部分を実際に動かして検証すること、それを行いやすい開発環境や開発プロセスとするために工夫や改善を行うことは非常に重要です。

少し話しが AS7 の紹介からそれました、 AS7 では Arquillian というテスティングフレームワークによりコンポーネントのテストが容易になっています。これについては凄く興味深いのですが鋭意勉強中です。

Arguillian のロゴを見てるとかっぱ寿司の CM に登場する宇宙人を思い出します。

モジューラー設計

No more jar 地獄

階層型クラスローダには問題があり、デプロイメントの失敗や奇妙な振る舞いをしばしばします。親委譲モデルに別れを告げモジュラリティの方法を探しましょう。

というのがモジューラー設計考察へ至る問題提起として挙げられています。

AS7 では JBoss Modules により依存性におけるアプリケーションの隔離、サーバ実装クラスのアプリケーションからの隠蔽、オンデマンドクラスローディングを実現しています。 Module はクラスのコレクションをパッケージングしたもので、明示的に別のモジュールからの依存関係を指定しない限り依存性が隔離されます。この可視性規則はデフォルトでありカスタマイズ可能です。

この部分については高速化/軽量化(※ 後述)に並ぶ重要な変更点です。モジューラー設計に関連する概念として、module, extension が設定ファイルや AS7 内部のディレクトリに登場します。依存性のカスタマイズも一元管理可能な設定ファイル上で柔軟に変更可能です。

オンデマンド クラス ロード

JBoss Modules はアプリケーションが必要としたタイミングでクラスを(並列処理により)高速にロードします。

OSGi 的な?

AS7 は OSGiとの設計上の類似性により JBoss Modules および Module Service Container(MSC)上のレイヤーとしてのふるまいにより OSGi のサポートを提供します。

OSGi の補足を簡単にしておくと、 OSGi はモジュール(ソフトウェアにおける一般的なモジュールの概念を指しています、 JBoss Module 固有の Module ではありません。)の動的な追加/実行やネットワーク経由のやりとりを行うためのフレームワークで JVM 上のレイヤーとして動作します。(※ OSGi 実装の有名なものとして、 Equinox, Felix 等があります。Eclipse のプラグインがまさに OSGi バンドルなのでご存知の方も多いかもしれません。)

OSGi ではモジュールをバンドルと呼びます、OSGi を使用することにより Java の通常のパッケージング形式(jar)よりも柔軟(動的変更、バージョニング)なモジュール管理が可能です。

AS7 は前述の通り、 AS7 コア上のレイヤーとして OSGi をサポートするため、 OSGi バンドルを使用することが可能です。

非常に軽量

メモリダイエット

AS7 は GC の停止時間を最小限にするためにメモリ管理にアグレッシブな改善が加えられています。 jar ファイルに関するインデックスデータや必要に応じてロードする仕組み等がそれにあたります。これらのアプローチによりメモリ使用量が劇的に削減されています。

僕の環境(MacBook Pro Early 2011)だとピュアな状態の 7.0.1(standalone)で 140MB のメモリを使用するのに対して、 5.1.0(default プロファイル)が 470MB のメモリを使用するので AS を単に起動しただけの状態であれば 2/3 強のメモリが削減されていますね。

JMS, EJB, Mail 等を使用した場合どうなのかを今後は見ていきましょう。

前述の最適化により、 AS7 はこれまで蓄積した JVM 設定の使用やハードウェアリソースの少ないスモールデバイスでの使用も可能です。

スモールデバイスはさておき AWS 等のクラウド上で動かしやすくなることは素晴らしいですね。

また、 profile のカスタマイズにより不要な機能(mail, messaging 等)の削除を行う等のカスタマイズにより健全な状態のサーバを運用することが可能です。

サービスのカスタマイズが可能なこの機能自体は JMX コンテナ上でサービス(機能)が構成されていたこれまでのバージョンと同様ですね。

MSC(Modular Service Container)

AS7 の各種機能は個別のサービスにアレンジされ、サーバ実行時に構成/管理されます。

各々のサービスの起動/停止は隔離され、サービス間の最小限の依存性は実行時に調整されることによりサービスの並列制御を可能にしています。(マルチコア向きの管理方式万歳!)

MSC(Modular Service Container)アーキテクチャが起動/デプロイメントが高速された最も重要な要因です。

モジュール管理の仕組みとして新たに JBoss Modules (プロジェクトとして立ち上がっています。JBoss Modules Project )が定義されていて、その実行エンジンが MSC という感じです。

当然、これまでの AS コアである JBoss Microcontainer が JBoss Modular Service Container(MSC) に置き換えられています。JBoss Modules は非常に興味深いものがあるので今後 Deep Dive したいと企んでいます。

JBoss Modules に興味がある方へ! ドキュメントはこちら! JBoss Modules Documtnts

エレガントな管理

一元化された 設定 & 管理

AS7 の設定は一元化され、簡潔でユーザフレンドリーなものになっています。設定ファイルは domain モデル向きのものになっており、理解しやすく AS の内部構造が露出しない形式(AS の内部構造が設定ファイル中に存在すると本質的な部分が読み難くなります。)となっています。

一元化された設定は管理作業も統合します。 domain 中の複数の server では同一の設定ファイルを共有することが可能です。

上述の文では色々なことをぼやぼやっと説明しているのですが、ポイントは次の通りです。

・設定ファイルは domain/standalone モードに関係なく一元化

・domain モードでは domain 中の server で設定の共有が可能

これまでの設定ファイルはサービス毎(JBoss Web, DataSource 等)に色んな XML ファイルに分散されていたのですが、それらが一箇所(domain.xml, standalone.xml, host.xml)にまとめらています。

管理はかなり楽になるんではないでしょうか、これまでの運用手順書等のドキュメントや運用プロセスの対応がちょっと面倒ですが。。。

domain モードについては待望の新機能です、クールです。

コマンド中心の管理方式

AS7 ではこれまでのものに比べ洗練されユーザフレンドリーな web コンソールや CLI 、スクリプトや外部プログラムのための AS 管理用 Java API, HTTP API を使用しての設定の永続化や管理が可能です。

管理用 API がスクリプトやツール作成用のプログラム向けの API であるのに対して、 web コンソールは実行時の AS の簡潔なビュー(DataSource, Deployment, …)を提供します。

AS7 の管理インターフェース改善で最も便利なのが、設定の変更が永続化されるということであり、これにより設定ファイルへの面倒な修正の手間が軽減されます。

web コンソールは今のところ DataSouorce設定、JNDI照会、ロギング設定、アプリケーションのデプロイ/アンデプロイ、IPアドレス/ポート設定、システムプロパティ設定が行えるようになっています。

他のアプリケーションサーバ製品に比べ機能や UI が見劣りするのは開発中だからだ!と信じてます。

管理ツール面での大きな変更が、 twiddle から CLI へコマンドラインツールが変更されたことです。twiddle は JMX の MBean に対して属性値を照会/変更するものでしたが、 CLI は全くの別物です。

CLI を使用して、 JMC, DataSouce, Deploy/Undeploy といったリソースの管理や設定ファイル(XML)中の要素(属性)のノード構造にアクセスして値を変更することができます。

あと、web コンソールもしくは CLI 経由で行った設定変更は設定ファイルに(一元的に)永続管理されるところが素晴らしい。

標準仕様への対応

Java EE 6 Web Profile

JBoss はこれまでベンダーロックインを避けるためアプリケーションのポータビリティを念頭に開発が行われてきました。 AS7 も当然このポリシーのもと開発され Java EE 6 Web Profile の認定を受けています。

そして、 Full Profile の認定に向け鋭意開発中です!

AS7 は Arquillian ベースの内部テストを行うことにより、コミュニティユーザが期待するポータビリティのための厳格な標準準拠を成し遂げています。

アプリケーションが Java EE 使用に準拠していれば、そのアプリケーションは AS7 で動作すると考えられます。アプリケーションが AS7 で動作しな場合、アプリケーションがポータビリティの面で問題を抱えている可能性を示唆しています。

Full Profile の認定はまだ取得されていません、一般的にあまり使わない機能の未サポートはまぁいいとして Full Profile バージョンで EJB を動かしてもタイマー等が動かないのには注意は必要です。

標準化についての話題についてはあまり興味が無いので解説を割愛します、なぜあまり興味が無いかは追々話します、何をもって標準とするか。。。それだけで保守性や開発効率がどこまで効率するのか。。。難しいところです。

OSGi Core 4.2 

AS7 は Java EE 適合とおなじように OSGi 適合が考慮されています。

AS7 コアのモジュラー設計により、 OSGi 準拠が自然な形で対応しており、 OSGi 準拠だけでなく OSGi と Java EE コンポーネントの統合も可能です。

OSGi は素晴らしいです、何故素晴らしいか?アプリケーション開発者や運用面でどんなメリットがあるのか?についての調査検証も追々やっていきますよ、追々ね。

テスト容易性

Arquillian

AS7 は開発初期の段階からテスト容易性の考慮が行われています。Arquillian – 実行環境中で実行可能な統合テストのためのコンポーネントモデル がそれを可能にしました。

Arquillian は開発/テストから煩雑性を排除することにより、アプリケーションが直面するユースケースにフォーカスしたテストが可能にします。

AS7 が高速化されたことにより、 Arquillian によるテストはユニットテストと同等の速度で実行可能です。

スマート開発

開発に Arquillian を使用することにより、 Java EE 等のコンポーネントに対する 変更、コンパイル、テスト のサイクルが効率化されます。

これにより、テスト駆動開発がこれまで以上に容易になります。

AS7 は Arquillian を使用した開発がいかに効果的かあるいは(あなたの開発する)ソフトウェアがいかに堅牢かの証明です。

テスト容易性の向上はかなりクールなポイントですね。 何とかコンポーネントはテストし難いというネガティブな台詞が根絶されるためにも色々検証していきます。

今回は JBoss AS7 の概要をみてみました。次回以降はドキュメントの意訳/解説とドキュメントに書いてあることを実際に検証していこうと思います。

タグ: ,