JBoss AS 7 – Getting Started Developing Applications Guide – Getting started with JBoss AS

今回は開発環境構築に関するお話です。Eclipse + JBoss Tools のインストールと Maven プロジェクトのインポートや Eclipse からのデプロイ/アンデプロイやデバッッグに関するお話です。

JBoss Tools についてる Maven のプラグインがなかなかの使い心地です。クールとはいかないまでもそれなりに。。。

1 週間程マカオに出張に行っており前のエントリからちょっと時間が経ってしまっていますが、ここからはガシガシ AS7 の素晴らしさを世に知らしめていこうと思います!

Getting started with JBoss AS

examples アプリケーションを同梱されるビルドスクリプトを使用して動作させるには以下のソフトウェアが必要になります。

  • JDK 1.6.x
  • Apache Maven 3.0.x
  • JBoss AS 7
  • JBoss AS 7 Quick Starts
  既にこれらのソフトウェアが導入されていれば再度インストールする必要はありません。

AS7 のインストール対象プラットフォームで実行可能な Java 実行環境( JDK )を選択し、マニュアルに従いインストールを行って下さい。例として以下の JDK が選択可能です。

Maven 3 ※1 がまだインストールされていない場合オフィシャルガイド ※2 を参照して下さい。

以下のコマンドを実行することにより、インストールされている Maven のバージョンを確認することができます。

mvn –version

ヴァージョン 3.0.0 以降がインストールされていれば examples アプリケーションのビルドが可能です。

※1 Apache Maven , Maven 3 Doanload

※2 Maven Getting Started Guide

以降では Eclipse を使用した examples アプリケーションのデプロイ方法について紹介します。

JBoss AS 7 を JBoss AS download page からダウンロード済みの状態を前提として解説を行います。

 JBoss AS 7 は複数の AS インスタンスを一元管理する機能を提供します。これら AS インスタンス( server )の集合は “domain” のメンバーとみなされ、 Domain Controller プロセスが管理ポイントとして動作します。”domain” は複数の物理(あるいは仮想)マシーンにまたがって構成することが可能です。個々の物理(あるいは仮想)マシーン(ホスト)上では Host Controller プロセスがそのホスト上の AS インスタンスの管理を行います。Host Controller は Domain Controller と AS インスタンスのライフサイクル管理や Domain Controller サポートをするために連携を行います。AS7 は standalone モードで稼働されることも可能で、quickstart example アプリケーションの動作確認では standalone を使用します。

Installing and starting JBoss AS on Linux, Unix or Mac OS X

最初に、以降で紹介するコマンドを実行し JDK と Maven が正しくインストールされているかの確認を行って下さい。

java -version

上記の実行結果から JDK のバージョンが 1.6.0 以降であることを確認して下さい。次に以下のコマンドを実行して下さい。

mvn –version

上記の実行結果から Maven のバージョンが 3.0.0 以降であることを確認して下さい。

次に、 JBoss AS のインストールディレクトリを選択します、デフォルトでは JBoss AS 7 は jboss-7.x.x.x ディレクトリに展開されます。( 7.x.x.x はダウンロードバージョンを表します。)

インストール対象ディレクトリにダウロードした JBoss AS 7 の zip ファイルを解凍して下さい。

unzip jboss-7.x.x.x .zip

それでは JBoss AS を standalone モードで起動してみましょう。

jboss-7.x.x.x/bin/standalone.sh

  JBoss AS の停止には AS を(フォアグラウンドで)起動したターミナルで Crtl-C を実行して下さい。

以上で JBoss AS のインストールと起動ができました。 http://localhost:8080/ にアクセスし server が正しく起動しているかを確認して下さい。

  モードの場合、ログファイルは jboss-7.x.x.x/standalone/log/server.log にあります。Getting Started Guide ではロギング設定についてより詳しい内容が紹介されています。

Installing and starting JBoss AS on Windows

インストール手順は Linux, Unix, Mac OS S と同様です。

これらの OS と同様の手順で jboss-7.x.x.x を展開後、以下を実行し動作確認を行って下さい。

boss-7.x.x.x/bin/standalone.bat

Starting JBoss AS from Eclipse with JBoss Tools

JBoss AS の起動やアプリケーションのデプロイについて、コマンドラインより Eclipse による方法を選択する場合、以降を参照して下さい。
JBoss AS を Eclipse から使用するためには、JBoss AS をインストールする必要があります。上述のガイドに従い JBoss AS のインストールと起動確認を行って下さい。
JBoss  AS を Eclipse から使用するためには、 Eclipse Indigo ( Eclipse 3.7 ) と JBoss Tools 3.3 M2 以降が必要になります。quickstarts アプリケーションを Eclipse から起動した場合は m2eclipse も必要になります。

Eclipse, m2eclipse, JBoss Tools のインストール方法は JBoss Tools Site に記載があります。 Maven Support feature と Java EE Development feature のインストールを確認して下さい。

Eclipse と JBoss Tools のインストールについて補足します。手順は以下の通りです。

     1. Eclipse Downloads から Eclipse 3.7.x をダウンロードします。※ Java EE Developers をダウンロードします。

     2. Eclipse を適当なディレクトリで起動して、 [Help] -> [Install New Software] を選択します。

     3. [Add] を選択し以下を入力します。

Name: JBoss Tools 3.3

Location: http://download.jboss.org/jbosstools/updates/development/indigo/

add repository

     4. Available Software ウィンドウにおいて [All JBoss Tools 3.3] [Application Development] [Maven Support] [Web and Java EE Development] を選択状態にし [Next] を選択します。

available software

     5. Install Details ウィンドウで [Next] を選択します。

install

     6. Revie Licenses ウィンドウで [I accept …] を選択状態にし [Finish] を選択します。

review license

     7. Software Updates ウィンドウで [Restart Now] を選択し Eclipse の再起動を行います。

     8. Eclipse のインストールと起動が正しくできたら、 JBoss AS を Eclipse に追加する必要があります。

          最初に、以下の通り [File] -> [New] -> [Other] を選択して下さい。

new server

     9. 新規サーバ(New Server)ウィザードを選択します。

select a wizard

     10. [JBoss AS 7.x] を選択します。

new server

     11. [Server name:] に任意の適切な名前を入力し [Next] を選択します。

          JBoss Runtime ウィンドウで Name に任意の適切なランタイム名と Home Derectory に AS7 のインストールディレクトリを指定し [Finish] を選択します。

jboss runtime

     12. AS7 を Eclipse から起動するには Servers ビューを使用します。

          前述の手順で登録した AS7 ランタイムが Servers ビューに表示されるので、それを選択し右クリックから [Debug] もしくは [Start] を選択し AS7 を起動します。別の AS7 プロセスが起動している場合そちらを停止します。

          ※ Servers ビューが表示されていない場合、[Window] -> [Show View] -> [Others…] -> [Server] -> [Servers] を選択し Servers ビューを表示させて下さい。

servers view

start server

  AS7 ランタイム上にデプロイしたアプリケーションのデバックを行う場合、 [Start] ではなく[Debug] を使用して AS7 を起動して下さい。これにより AS7 はデバッグモードで起動され Eclipse デバッガにアタッチされます。

     13. AS7 を起動すると Console ビューにサーバログが出力されます。

console view

Importing the quickstarts into Eclipse

quickstarts アプリケーションを Eclipse にインポートするには m2eclipse プラグインが必要になります。

※ 前述 4. の手順により m2eclipse のインストールは完了しています。 m2eclipse は Maven プロジェクト( pom.xml )を Eclipse と連携させるプラグインです。厳密には Maven から Eclipse プロジェクトのメタファイル( .project )を生成( mvn eclipse:eclipse )することにより m2eclipse プラグインを使用せずに Maven で構築されたプロジェクトを Eclipse に認識させることも可能です。

     1. [File] -> [Import…] -> [Maven] -> [Existing Maven Projects] を選択します。

new import

select maven project

     2. quickstarts ディレクトリ( quickstarts を解凍したルートディレクトリ)をファイルブラウザで指定します。

select directory

     3. Maven Projects ウィンドウで 4 プロジェクトが選択状態にあることを確認し [Finish] を選択します。

maven project

     4. Maven プロジェクトのインポートが成功すると Package Explorer に以下の 4 プロジェクトが表示されます。

※ プロジェクトのインポートは依存するライブラリを Maven のリモートリポジトリからのダウンロードも行われるので多少時間がかかる場合があります。

imported project

     5. jboss-as-helloworld を例に Eclipse を使用した Maven アプリケーションのデプロイ/アンデプロイについて補足します。

アプリケーションの Eclipse からのデプロイ/アンデプロイにはデプロイ対象の Server に対象アプリケーションを追加( Add )/削除( Remove )することにより行います。

Servers ビュー上のデプロイ対象サーバを右クリックし表示されるコンテキストメニューから [Add and Remove…] を選択します。

add server

     6. Add and Remove ウィンドウが表示され [Available] に追加可能なプロジェクトの一覧が表示されます。

select add project

     7. 今回は jboss-as-helloworld プロジェクトをデプロイします。

project selected

     8. jboss-as-helloworld が選択された状態で [Add >] を選択し同プロジェクトを [Configured] に移動させ [Finish] を選択します。

jboss-as-helloworld が AS7 にデプロイされコンソールビューにデプロイ成功ログが出力されれば成功です。

deploy log

デプロイはアプリケーションアーカイブ( war/ear …)を $JBOSS_HOME/standalone/deployments に配置することで実現しているようです。

上記のログでは MSC のスレッドが 4 つ稼働しているのが分ります。jpa, weld, web コンテナですね。web コンテナのログからアプリケーションのコンテキストルートが /jboss-as-helloworld であることがわかりますね。

ブラウザからアプリケーション <http://localhost:8080/jboss-as-helloworld&gt; にアクセスしてみましょう。。。まぁ “Hello World!” を出力する味気ない画面が表示されるだけですが。

管理コンソールの [Deployments] -> [Manage Deployments] からjboss-as-helloworld.war がデプロイされていることが確認できます。

CLI を使用すれば、 jboss-as-helloworld.war のリソースを階層構造で辿っていくことが可能です。

以下のコマンドを実行すると HelloWorldServlet のリソース情報が参照可能です。

/deployment=jboss-as-helloworld.war/subsystem=web/servlet=org.jboss.as.quickstarts.helloworld.HelloWorldServlet:read-resource

read resource

CLI は設定やデプロイされたアプリケーションや JMS, Datasource をリソースという概念で木構造で管理するスタイルをとっています。

上述のコマンドは /deployment=jboss-as-helloworld.war/subsystem=web/servlet=org.jboss.as.quickstarts.helloworld.HelloWorldServlet というリソースに対して read-resource というコマンドを実行しています。

木構造を辿る際やあるリソースに対して実行可能なコマンドはタブにより補完されます。上記のコンソールのスクリーンキャプチャでは /deployment=jboss-as-helloworld.war/subsystem=web/servlet=org.jboss.as.quickstarts.helloworld.HelloWorldServlet リソースを明示した状態でタブを使用することにより使用可能なコマンドの一覧が表示されています。

CLI を使用してアプリケーションのアンデプロイも可能なので試してみましょう。

undeploy command

jboss-as-helloworld アプリケーションの中身を少しみてみましょう。

コンテキストルート “/jboss-as-helloworld” をブラウザから指定すると “/jboss-as-helloworld/HelloWorld” にリダイレクトされ org.jboss.as.quickstarts.helloworld.HelloWorldServlet サーブレットが駆動します。

HelloWorldServletサーブレットは Servlet 3.0 の仕様に対応して実装されているので @WebServlet(“/HelloWorld”) のアノテーションにより web.xml 無してサーブレットの登録と URL マッピングが実現されています。

同サーブレットは org.jboss.as.quickstarts.helloworld.HelloService というクラスを CDI の @Inject アノテーションを使用して実現しています。ここではまたインターフェース無しのクラスをインジェクションしていたりします。

CDI やその実装である Weld については neverbird さんの なるほど!ザ・Weld で詳しく解説されているのでぜひ参考にして下さい。

Managing JBoss Application Server

AS7 の管理は web 管理コンソール(以降 管理コンソール)もしくはコマンドラインインターフェース(以降 CLI )を使用して行います。これらの詳細は Admin Guide を参照して下さい。

サーバが起動した状態であれば、管理コンソールは <http://localhost:9990/console&gt; からアクセス可能です。管理コンソールからはデータソース、デプロイ サーバ設定等の管理が可能です。

CLI は以下のように jboss-admin.sh もりくは jboss-admin.bat スクリプトを実行して起動します。

$JBOSS_HOME/bin/jboss-admin.sh –connect

CLI起動後は help コマンドにより使用可能なコマンドの情報が表示されます。

本ガイドを通して、アプリケーションのデプロイ/アンデプロイには jboss-as maven プラグインを使用します。

このプラグインは AS7 との連携(通信)に JBoss AS Native Java Detyped Management API を使用します。

管理コンソール/CLIの詳細については Admin Guide – Management Clients を参照して下さい。

タグ: , ,

JBoss AS 7 – Getting Started Developing Application Guide – Introduction

クールにサクッと翻訳だけしました。あまり読む必要は。。。無いです。


イントロダクション

このガイドでは、 AS7 のインストールとスタートアップについて案内します。また( JBoss AS 7 が認定をうけている)Java EE ( Web Profile )のプログラミングモデルの特徴について紹介します。

   Java EE 6

Java EE 6 により開発者は分散可能でトランザクションに対応し移植性に優れたアプリケーションを素早く簡単に開発することが可能です。このような機能が要求されるアプリケーションは “エンタープライズアプリケーション” に分類されると考えられます。これらのアプリケーションには高速かつセキュアで高い信頼性が必要です。

Java EE は SOAP( JAX-WS )を使用した web サービスだけでなく強力なメッセージング( JMS )、トランザクション管理( JTS )、外部リソース接続( JCA )の機能を提供してきました。 Java EE 5 からは、宣言的で軽量な O/R マッピング( JPA )、アノテーションの使用、コンポーネントへのアクセス容易性等のために根本的なプログラミングモデルの転換が計られました。

Java EE 6 では、タイプセイフ、疎結合なプログラミングモデル( CDI )、データの制約に対する宣言的な検証( Bean Validation )、 RESTful web サービス( JAX-RS )の機能追加が行われています。

AS7 は慣れ親しんだ以前の AS のバージョンの構造とは違ったものとなっています。そのため、 Getting started with JBoss AS を参照することを推奨します。

AS7 には最小限の手間でアプリケーションが記述できるようになるための クイックスタート があります。下記の順序に従いクイックスタートの動作/ソースコードを確かめることを推奨しますが、 EE6 の経験がある場合、これらをスキップすることもできます。

Core  
Helloworld quickstart JSF, Wicket, EJB, Spring を使用したアプリケーションの開発経験がある場合、このクイックスタートをスキップすることもできます。
Numberguess quickstart JSF, Wicket, EJB, Spring, JPA, Hibernate を使用したアプリケーションの開発経験がある場合、このクイックスタートをスキップすることもできます。 
Login quickstart Java EE の達人であればこのクイックスタートをスキップすることもできます。
Kitchensink quickstart すばらしいスタートポイントです。
Optional  
Helloworld OSGi quickstart  JBoss AS で OSGi を動かしたい場合、このクイックスタートをチェックして下さい。

クイックスタートのダウンロード

クイックスタートは JBoss AS と一緒に( JBoss AS ランタイムとは別 )配布されています。JBoss AS ダウンロードページ から最新版を入手して下さい。

タグ: , ,

JBoss AS 7 Admin Guide – Management tasks – Command line parameters

今回は AS7 の起動スクリプトと AS のバインドアドレスや AS のディレクトリをカスタマイズする場合に使用するシステムプロパティについて書かれた Command line parameters について解説します。前回のエントリで Core management concepts の解説の途中段階ではありますが、これを知ってると色々便利なので。

あと、今回から解説対象のマニュアルを 7.1 系の JBoss AS Document に変更しています。 7.1 系はまだリリースされていませんがドキュメントだけはでているようです。。。

内容も 7.0 系のものとはちょっと違ってました。

Command line parameters

Domain / Standalone それぞれのモードにおいて domain.sh / standalone.sh を引数無しで実行した場合、デフォルトの設定を適用された AS7 が起動します。

以降の説明では、これら起動スクリプト実行時に引数を与えるまたは起動スクリプトを呼び出す独自スクリプトから引数を設定することでデフォルトの設定を上書きする方法について紹介します。

System properties

Domain / Standalone それぞれのモードは設定ファイルやデータの書込みディレクトリが標準位置にあることを想定したデフォル設定を使用します。

これファイルやディレクトリの標準的な位置はシステムプロパティで設定されており、システムプロパティにはデフォルト値があります。

システムプロパティを上書きするには、起動スクリプトに [-Dkey=value] 形式の jvm オプションパラメータを与えて AS を起動します。

$JBOSS_HOME/bin/standalone.sh -Djboss.home.dir=some/location/AS7/jboss-as \-Djboss.server.config.dir=some/location/AS7/jboss-as/custom-standalone

上記の例では、カスタマイズされた jboss.home.dir (ホームディレクトリ)と jboss.server.config.dir (設定ディレクトリ)を使用して standalone server  インスタンスを起動しています。特定のシステムプロパティに関する詳細については以降で解説する定義を参照して下さい。

システムプロパティの設定にはjvm オプションパラメータによるもの以外に、プパティファイルに [キー=バリュー] 形式で値を設定し起動スクリプトでこのプロパティファイルを指定することによる設定も可能です。(以下の例を参照して下さい。)

$JBOSS_HOME/bin/domain.sh –properties=/some/location/jboss.properties
$JBOSS_HOME/bin/domain.sh -P=/some/location/jboss.properties

起動スクリプトでプロパティファイルを指定するパラメータとプロパティファイルのシンタックスは domain.sh, standalone.sh あるいは MS Windows で使用される domain.bat / standalone.bat で同様となります。

プロパティファイルは [キー=バリュー] ペア形式の標準的な Java プロパティファイルとなります。

jboss.home.dir=/some/location/AS7/jboss-as
jboss.domain.config.dir=/some/location/AS7/custom-domain

Standalone

プロパティ名 使い方 デフォルト値
java.ext.dirs JDK 拡張ディレクトリの指定 null
jboss.home.dir JBoss AS 7 のルートディレクトリ standalone.sh 内で $JBOSS_HOME 変数として設定
jboss.server.base.dir server のベースディレクトリ jboss.home.dir/standalone
jboss.server.config.dir 設定のベースディレクトリ jboss.server.base.dir/configuration
jboss.server.data.dir 永続化データ(ファイル)の配置ディレクトリ jboss.server.base.dir/data
jboss.server.log.dir server.log ファイルの配置ディレクトリ jboss.server.base.dir/log
jboss.server.temp.dir 一時ファイルの配置ディレクトリ jboss.server.base.dir/tmp
jboss.server.deploy.dir デプロイされたコンテンツの配置ディレクトリ jboss.server.data.dir/contentjboss.server.data.dir/deployments

Managed Domain

プロパティ名 使い方 デフォルト値
jboss.home.dir JBoss AS 7 のルートディレクトリ domain.sh 内で $JBOSS_HOME 変数として設定
jboss.domain.base.dir domain のベースディレクトリ jboss.home.dir/domain
jboss.domain.config.dir 設定のベースディレクトリ jboss.domain.base.dir/configuration
jboss.domain.data.dir 永続化データ(ファイル)の配置ディレクトリ jboss.domain.base.dir/data
jboss.domain.log.dir host-controller.log と process-controller.log ファイルの配置ディレクトリ jboss.domain.base.dir/log
jboss.domain.temp.dir 一時ファイルの配置ディレクトリ jboss.domain.base.dir/tmp
jboss.domain.deployment.dir デプロイされたコンテンツの配置ディレクトリ jboss.domain.base.dir/content
jboss.domain.servers.dir domain で管理される server インスタンスの出力を含むディレクトリ jboss.domain.base.dir/log

Other command line parameters

AS7 起動スクリプトの引数を用いた [名前=値] 形式のパラメータ指定(コマンドラインパラメータ)が可能です。

–name=value

(例)

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

パラメータ名が単一文字の場合、 ‘–‘ の代わりに ‘-‘ を使用することが可能です。

-x=value

(例)

$JBOSS_HOME/bin/standalone.sh -P=/some/location/jboss.properties

以前の JBoss AS のメジャーリリースで頻繁に使用されていたコマンドラインパラメータでは、互換性を保つために上記の例における “=” の スペース での代用がサポートされています。(以下の例を参照)

-b 192.168.100.10

AS7 で新たに導入されたコマンドラインパラメータについては [-x=value] 形式のシンタックスをサポートします。

次のセクションでは standalone / domain のそれぞれのモードで指定可能なコマンドラインパラメータを示します。

Standalone

名前 指定しない場合のデフォルト値
–server-config jboss.server.config.dir/standalone.xml jboss.server.config.dir からの相対パスまたは絶対パス

Managed Domain

名前 指定しない場合のデフォルト値
–domain-config jboss.domain.config.dir/domain.xml jboss.domain.config.dir からの相対パスまたは絶対パス
–host-config jboss.domain.config.dir/host.xml jboss.domain.config.dir からの相対パスまたは絶対パス

次のコマンドラインパラメータは値を持たずスレーブの host constoller でのみ使用可能です。

名前 機能
–backup スレーブの host controller に domain 設定ファイルのローカルコピーを作成/保持させます。
–cached-dc スレーブの host controller が起動時にマスタの domain controller から設定を取得できない場合に、 [–backup] を使用して事前に作成された設定のローカルコピーを使用して起動します。スレーブの host controller には domain 設定の修正が適用されないが、サーバの起動は可能です。

Common parameters

次のコマンドラインパラメータは standalone / domain の両起動スクリプトで適用可能です。

名前 機能
-b=<value> システムプロパティ jboss.bind.address に <value> を設定します。詳細は “Controlling the Bind Address with -b” を参照して下さい。
-b<name>=<value> システムプロパティ jboss.bind.address.<interface> を設定します。 <interface> は変更可能です。詳細は “Controlling the Bind Address with -b” を参照して下さい。
–version-v-V JBoss AS のバージョンを標準出力に表示し終了します。
–help-h 起動スクリプトオブションについてのヘルプを表示し終了します。

Controlling the Bind Address with -b

JBoss AS はソケットを standalone.xml, domain.xml, host.xml 中の <interfaces> 要素に含まれる IP アドレスインターフェース にバインドします。(詳細は Interfaces と Socket Bindings を参照して下さい。)

<interfaces>

<interface name=”management”>

<inet-address value=”${jboss.bind.address.management:127.0.0.1}“/>

</interface>

<interface name=”public”>

<inet-address value=”${jboss.bind.address:127.0.0.1}“/>

</interface>

</interfaces>

これらの設定はシステムプロパティ jboss.bind.address.management および jboss.bind.address により行われ、デフォルト値はそれぞれ 127.0.0.1 となります。

Common Parameters” で解説されているように、 JBoss AS は “-b” および -b <name> コマンドラインスイッチ(パラメータ)をサポートします。これらのスイッチは jboss.bind.address および jboss.bind.address.<name> のシステムプロパティを設定します。

インターフェース設定が前述のものと同様で次のコマンドを使用して AS を起動した場合、 “public” と命名されたインターフェースのソケットは 192.168.100.10 にバインドされます。

$JBOSS_HOME/bin/standalone.sh -b=192.168.100.10

標準的な(デフォルトの)設定ファイルでは、 “public” インターフェース サーバ管理用の “management” インターフェースには結びついていません。
“public” インターフェースはエンドユーザのアクセスを処理します。

   Interface names

“public” インターフェースは特別ではなく便宜上提供されているものです。環境に合わせ独自のインターフェース名を与えることが可能です。

全ての IPv4 アドレスに public インターフェースをバインドするには次のようにして下さい。

$JBOSS_HOME/bin/standalone.sh -b=0.0.0.0

また、 management インターフェースを次のようにバインドすることも可能です。

$JBOSS_HOME/bin/standalone.sh -bmanagement=192.168.100.10

標準的な設定ファイルでは、 “management” インターフェースはサーバ管理に結びついたソケットとなります。 CLI が使用するソケット、管理コンソールが使用する HTTP ソケット、 JMX コネクタソケットがこれにあたります。

   Be Careful

-b スイッチはデフォルトで提供される設定ファイルのインターフェース(<inet-address>要素)のバインディングのみを制御します。設定ファイルの <interfaces> の子要素を <inet-addresse> から変更した場合、 -b コマンドスイッチによるインターフェースのバインディング指定は無視されます。

例えば、次の “public” インターフェースに対する設定により -b スイッチによる “public” に対する設定は無視されます。

<interface name=”public“>

<nic name=”eth0“/>

</interface>

重要なポイントは 設定ファイルによる設定内容が設定を定義し、 -b スイッチによる設定は設定ファイルの設定内容を上書きしないということです。コマンドラインパラメータはシステムプロパティを設定するための簡潔なシンタックスを便宜のために提供します。

上記の注意点( Be Careful )はかなり意訳をしたつもりなのですがそれでも意味が分かり難いので、解説が必要ですね。

インストール直後の AS7 の設定ファイル( standalone.xml )のインターフェース設定は以下の通りになっています。

<interfaces>

<interface name=”management“>

<inet-address value=”${jboss.bind.address.management:127.0.0.1}“/>

</interface>

<interface name=”public“>

<inet-address value=”${jboss.bind.address:127.0.0.1}“/>

</interface>

</interfaces>

-b スイッチによるバインディングの設定はあくまで jboss.bind.address もしくは jboss.bind.address.management システムプロパティの値を変更するためのものです。上記の設定ファイルでは “management”, “public” がそれぞれ jboss.bind.address.management, jboss.bind.address を参照しているため、起動スクリプトの -b スイッチに与えたバインドアドレスがそれぞれのいいターフェースのバインドアドレスとして使用されます。

設定ファイルを以下のように設定した場合、前述のシステムプロパティがインターフェースのバインディング設定に使用されていないためバインドされるアドレスは -b スイッチの指定に従いません。

<interfaces>

<interface name=”management“>

<nic name=”eth0” />

</interface>

<interface name=”public“>

<inet-address value=”${jboss.bind.address:127.0.0.1}“/>

</interface>

</interfaces>

以降にシステムプロパティ/コマンドラインパラメータに関する実験とヒントを記述しておきます。是非実際に動かして動きを確認してみましょう!

[ex 1.]

ログ( server.log )の出力位置を変更する。

[ex 2.]

<http://${IPアドレス}:8080> と <http://${IPアドレス}:9990> にブラウザからアクセスした場合、前者のみアクセス可能なよう JBoss AS のバインドアドレスを変更する。

※ ${IPアドレス}にはJBossを稼働させるホストのIPアドレスを指定して下さい。

[ex 3.]

<http://${IPアドレス}:8080> と <http://${IPアドレス}:9990> にブラウザからアクセスした場合、後者のみアクセス可能なよう JBoss AS のバインドアドレスを変更する。

※ ${IPアドレス}にはJBossを稼働させるホストのIPアドレスを指定して下さい。

[ex 4.]

“public” インターフェースに対して <nic /> を使用してバインドアドレスを指定し、 -b 0.0.0.0 を指定して起動した場合の挙動を確認して下さい。


[ex 1. – hint]

起動スクリプト( standalone.sh )に -Djboss.server.log.dir=/var/log/jboss を与えることによりserver.log ファイルの配置位置を変更する。

[ex 2. – hint]

1. 起動スクリプト( standalone.sh )に -b 0.0.0.0, -b=0.0.0.0, -Djboss.bind.address=0.0.0.0 を指定する。

2. 設定ファイル( standalone.xml )の “public” インターフェースを以下のように指定する。

<interfaces>

<interface name=”management”>

<inet-address value=”${jboss.bind.address.management:127.0.0.1}”/>

</interface>

<interface name=”public”>

<inet-address value=”${jboss.bind.address:0.0.0.0}”/>

</interface>

</interfaces>

あるいは

<interfaces>

<interface name=”management”>

<inet-address value=”${jboss.bind.address.management:127.0.0.1}”/>

</interface>

<interface name=”public”>

<nic name=”${バインド対象のNIC名}” />

</interface>

</interfaces>

[ex 3. – hint]

1. 起動スクリプト( standalone.sh )に -bmanagement=0.0.0.0 を指定する。

2. 設定ファイル( standalone.xml )の “management” インターフェースを以下のように設定する。

<interfaces>

<interface name=”management”>

<inet-address value=”${jboss.bind.address.management:0.0.0.0}”/>

</interface>

<interface name=”public”>

<inet-address value=”${jboss.bind.address:127.0.0.1}”/>

</interface>

</interfaces>

あるいは

<interfaces>

<interface name=”management”>

<nic name=”${バインド対象のNIC名}” />

</interface>

<interface name=”public”>

<inet-address value=”${jboss.bind.address:127.0.0.1}”/>

</interface>

</interfaces>

[ex 4. – hint]

インターフェース設定は管理コンソールの General Configuration – Interfaces から確認できます。

タグ: ,

JBoss AS 7 Admin Guide – Core management concepts – General configuration concepts

今回から Admin Guide (管理ガイド)の解説を行います。管理ガイドはそれなりのボリュームがあるので、十数回に分けて解説します。

今回から 3 回に分けて Core management concepts パートの解説を行います。

第 1 回は General configuration concepts です。

General configuration concepts

domain / standalone 両モードに共通となるいくつかの設定について以降で解説を行います。

Extensions

エクステンションは JBoss のコア機能を拡張するモジュールです。 AS7 のコアは非常にシンプルで軽量であり、大抵のユーザが関心のあるほとんどの機能がエクステンションとして提供されています。エクステンションは $JBOSS_HOME/modules ディレクトリにモジュールとしてパッケージングされています。特定のモジュールを使用する場合、 domain.xml / standalone.xml の <extension /> 要素を使用してモジュール名を指定します。

<extensions>

[…]

<extension module=”org.jboss.as.transactions“/>

<extension module=”org.jboss.as.web” />

<extension module=”org.jboss.as.webservices” />

<extension module=”org.jboss.as.weld” />

</extensions>

Profiles and Subsystems

standalone.xml / domain.xml において重要な設定項目は単一( standalone.xml では単一のプロファイルが定義可能です。)あるいは複数のプロファイル( domain.xml では複数のプロファイルが定義可能です。)です。

プロファイルはサブシステムの名前付けされたセットになります。サブシステムはエクステンションにより AS7 コアに追加された追加機能セットになります。

サブシステムはサーブレット処理、EJBコンテナ、JTA等のサービスを提供します。プロファイルはサブシステム各々の詳細設定を伴うサブシステムの名前付きリストになります。

多数のサブシステムを伴うプロファイルは結果として多数の機能セットを伴うサーバとなります。少数のサブシステムにフォーカスしたプロファイルは小規模の機能のサーバとなりますがフットプリントが軽量になります。

個々のプロファイル設定の個々の内容は domain.xml と standalone.xml でほぼ同様のものとなります。

唯一の違いは、 Domain モードでは複数のプロファイルを設定可能ですが、 Standalone モードでは単一のプロファイルのみが設定可能ということです。

各々のプロファイルは一つ以上のサーバグループにマッピング可能です。

個々のサブシステム設定は domain.xml と standalone.xml で全く同じものとなります。

extension と subsystem の関係を web subsystem (JBoss Web)を例に解説します。

JBoss Web はこれまでのバージョンの AS でもサーブレットコンテナとして( AS のサービスとして)使用されています。これまでは sar 形式( JBoss 独自の形式)で MBean として AS に組込まれていましたが、 AS7 ではカーネルが MSC に変更されこれまでサービスとして扱っていたサーブレットコンテナ、データソース、メッセージングといった AS の機能はサブシステム( subsystem )として扱われます。

extension / subsystem の設定方法詳細は Admin Guide – Management tasks – Subsystem configuration の際に詳しく解説しますが、大きく次の手順になります。

  1. subsystem に必要な extension の設定( standalone.xml / domain.xml )
  2. subsystem の設定( standalone.xml / domain.xml)

standalone.xml の <extensions /> を見てみましょう。

<extensions>

<extension module=”org.jboss.as.web” />

</extensions>

web subsystem に必要な “org.jboss.as.web” extension(モジュール) が設定されています。※ モジュール( module )も AS7 で新たに導入された概念で extension と同義と考えられます。

上記の例では $JBOSS_HOME/modules/org/jboss/as/web/main に配置された module.xml がロードされ、必要なリソース( JBoss Web に必要な複数の jar ファイル)がモジュールとしてロードされます。( module.xml にはモジュールに必要なリソースと依存する他のモジュールが定義されています。)

subsystem にどんな extension が必要かについては Admin Guide – Management tasks – Subsystem configuration に、代表的な subsystem の設定方法と共に記述があります。

ちなみに、モジュール名とモジュールの配置位置は基本的に “a.b.c” => $JBOSS_HOME/modules/a/b/c/main/module.xml という関係になっています。

次に standalone.xml の <subsystem xmlns=”urn:jboss:domain:web:1.0″ …> を見てみましょう。

<subsystem xmlns=”urn:jboss:domain:web:1.0” default-virtual-server=”default-host”>

<connector name=”http” scheme=”http” protocol=”HTTP/1.1″ socket-binding=”http”/>

<virtual-server name=”default-host” enable-welcome-root=”true”>

<alias name=”localhost” />

<alias name=”example.com” />

</virtual-server>

</subsystem>

web subsystem の設定がされています。※ XML 名前空間は “urn:jboss:domain:web:1.0” となり、 $JBOSS_HOME/docs/schema/jboss-as-web_1_0.xsd が XML スキーマになります。

サーブレットコンテナに対する設定( JSP の解析に関する設定, Connector 設定等)は web subsystem に対して行います。

subsystem と XML 名前空間の関係については Admin Guide – Management tasks – Subsystem configuration に、代表的な subsystem の設定方法と共に記述があります。

※ web subsystem の設定方法詳細については Admin Guide – Management tasks – Subsystem configuration – Web subsystem configuration を参照して下さい。

Paths

ファイルシステムパスの論理名です。

domain.xml, host.xml, standalone.xml はパスが設定可能なセクションを含みます。これらの設定ファイル中の他のセクションはこのパスを論理名を使用して参照します。物理パス名はマシンにより異なるため、完全な詳細物理パスを含むよりむしろこの方法が一般的です。

例えば、ロギングサブシステムは、 ”jboss.server.log.dir” への参照を含みます。これはサーバの “log” ディレクトリを指します。

<file relative-to=”jboss.server.log.dirpath=”server.log“/>

AS7はユーザが設定ファイルに定義しなくても自動的にいくつかの標準パスを提供します。

  • jboss.home — JBoss AS のルートディレクトリ
  • user.home — ユーザのホームディレクトリ
  • user.dir — ユーザのカレント作業ディレクトリ
  • java.home – JDK インストールディレクトリ
  • jboss.server.base.dir — 個々のサーバインスタンスのルートディレクトリ
  • jboss.server.data.dir  永続化データ(ファイル)格納ディレクトリ
  • jboss.server.log.dir  ログファイル格納ディレクトリ
  • jboss.server.tmp.dir  一時ファイル格納ディレクトリ
  • jboss.domain.servers.dir  host コントローラが個々のサーバインスタンスのための作業エリアを作成するディレクトリ( Domain モードの場合のみ)

設定ファイルの <path /> 要素を追加することにより、上記の最初の 5 つのものを除いてパスの追加/上書きが可能です。

以下の例では、 jboss.server.data.dir/example ディレクトリに example という名前の論理パスを定義しています。

<path name=”example” path=”example” relative-to=”jboss.server.data.dir“/>

<path /> 要素の属性は以下の通りです。

  • name — パスの論理名
  • path — 実際のファイルシステムパス、 ‘relative-to’ 属性が指定されない限り絶対パスとして扱われます。 ‘relative-to’ が指定された場合、 ‘relative-to’ で指定されたパスへの相対パスとして扱われます。
  • relative-to — (オプション)前もって定義された他の論理パス名もしくはシステムの標準パス

domain.xml のパス要素については name 属性以外の属性を含める必要はありません。つまり、実際のファイルシステムのパスが何であるかの情報を含める必要はありません。(以下の例参照)

<path name=”x“/>

上記の設定例は単純に、 ” ‘x’ と命名されたパスがあり、 domain.xml の他のパートから参照可能” ということを意味しています。 ‘x’ により示される実際のファイルシステムの場所は、ホストに特化したものであるため各マシンの host.xml にて指定します。このアプローチをとる場合、各々のマシンの host.xml において実際のファイルシステムのパスを指定する必要があります。(以下の例参照)     

<path name=”x” path=”/var/x” />

standalone.xml で <path /> 要素を使用する場合、実際のファイルシステムパスを指定する必要があります。

Interfaces

ソケットがバインド可能なIPアドレス/ホスト名の論理名を表します。 

domain.xml, host.xml, standalone.xml はインターフェースが宣言可能なセクションを含みます。これらのインターフェース論理名は他のセクションからの参照が可能です。(インターフェースの物理的な詳細情報はマシンによって異なるため、この形式は個々のセクションでインターフェースの詳細を定義する形式よりも適切です。)

インターフェース設定はインターフェース論理名だけでなく実際に使用する物理アドレスの解決のための基準情報が含まれます。詳しくは Admin Guide – Management tasks – Interfaces and ports を参照して下さい。

domain.xml に含まれる <interface /> 要素には name 属性以外の属性を含める必要がありません、つまり、論理名に関連付いた実際のIPアドレスを指定する必要はありません。(以下の例参照)

<interface name=”internal”>

<nic name=”eth1″/>

</interface>

standalone.xml 中の <interface /> 要素はIPアドレスを定義するための基準情報を含む必要があります。

Socket Bindings and Socket Binding Groups

ソケットバインディングはソケットの名前付き設定になります。

domain.xml と standalone.xml は名前付きソケット設定が宣言可能なセクションを含みます。これらのソケット設定はその他のセクションから論理名により参照可能です。(ソケットの物理的な詳細情報はマシンによりって異なるため、この形式は個々のセクションでソケットの詳細を定義する形式よりも適切です。)詳しくは Admin Guide – Management tasks – Interfaces and ports を参照して下さい。

interface と socket-binding について standalone.xml を見てみましょう。

<interfaces>

<interface name=”management“>

<inet-address value=”${jboss.bind.address.management:127.0.0.1}“/>

</interface>

<interface name=”public“>

<inet-address value=”${jboss.bind.address:127.0.0.1}“/>

</interface>

</interfaces>

上の例では、 “management” と “public” という名前のインターフェースが設定されています。

“public” インターフェースは “jboss.bind.address” という名前のシステムプロパティもしくは起動時( standalone.sh )に -b スイッチでアドレスの指定がされていない場合、 “127.0.0.1” にバインドされます。

※ バインドアドレスの設定方法詳細については Admin Guide – Management taskd – Command line parameters を参照して下さい。

<socket-binding-group name=”standard-sockets” default-interface=”public”>

<socket-binding name=”http” port=”8080″/>

<socket-binding name=”https” port=”8443″/>

<socket-binding name=”jndi” port=”1099″/>

</socket-binding-group>

上の例では、”http”, “https”, “jdni” という名前のソケットバインディングがそれぞれ “8080”, “8443”, “1009” ポートに対して設定されています。

これらのソケットバインディングは “public” という名前のインターフェース(※  前述)を使用していますので、 “http” であれば 127.0.0.1:8080 にバインドされます。

ちなみに、 “http” は web subsystem の connector から参照されている(以下参照)ので、 web subsystem は 127.0.0.1:8080 をリスンします。

<subsystem xmlns=”urn:jboss:domain:web:1.0″ default-virtual-server=”default-host”>

<connector name=”http” scheme=”http” protocol=”HTTP/1.1″ socket-binding=”http“/>

</subsystem>

System Properties

システムプロパティは、domain.xml, host.xml, standalone.xml のいくつかの箇所で設定可能です。

standalone.xml 中のシステムプロパティはサーバの起動プロセスの一部として設定されます。 domain.xml, host.xml 中のシステムプロパティは各サーバ(server)の起動時に適用されます。

domain.xml, host.xml でシステムプロパティが定義された場合、それらがどのバーバに適用されるか(システムプロパティのスコープ)はそれらの定義場所により異なります。

     domain.xml のルート要素の子要素に設定されたシステムプロパティは全てのサーバに共有されます。

     domain.xml の <server-group /> 中の <system-property /> に設定されたシステムプロパティはそのグループ中の全てのサーバに共有されます。

     host.xml のルート要素に子要素に設定されたシステムプロパティは当該ホストコントローラが管理する全てのサーバに共有されます。

     host.xml の <server /> 中の <system-property /> に設定されたシステムプロパティは当該サーバ中で共有されます。

同一名のプロパティを複数箇所で設定した場合、 <server /> 要素中で設定されたものが host.xml のルート要素下で設定されたものより優先されます、host.xml で設定されたものは domain.xml で設定されたものより優先されます、 <server-group /> 中で設定されたものは domain.xml のルート要素下で設定されたものより優先されます。

デフォルトの domain.xml には以下のシステムプロパティ( “java.net.preferIPv4Stack”:”true” )が設定されています。

<system-properties>

<property name=”java.net.preferIPv4Stack” value=”true“/>

</system-properties>

このプロパティはルート要素の子要素に設定されているので、 domain に参加する全ての server に共有されます。

タグ: ,

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 の概要をみてみました。次回以降はドキュメントの意訳/解説とドキュメントに書いてあることを実際に検証していこうと思います。

タグ: ,