UIX開発者ガイド | ![]() 目次 |
![]() 前へ |
![]() 次へ |
このトピックは、ユーザーが特定のイメージがページに表示されない原因やエラー・ログ内のイメージ生成に関する不明なメッセージを調べる場合に役立ちます。「イメージの生成」のトピックで説明したように、ブラウザ・ルック&フィールのUIXの実装では、UIX Dynamic Imagesテクノロジを使用して、ボタンやタブ・バーなどのコンポーネントのイメージを実行時に動的に生成します。動的イメージ生成による柔軟性を実現するためには、デプロイ環境がイメージ生成に必要なグラフィック操作に対応している必要があります。UNIX環境の場合、通常これは特別な構成作業が必要であることを意味します。
このトピックでは、UNIX環境で動的イメージの生成を可能にする方法について説明します。イメージ生成を可能にする作業のほとんどは、AWTでの使用向けにXサーバーを構成する作業です。Sun社では、イメージ生成などの簡単なグラフィック操作にXサーバーを必要とする不便さが認識されています。AWTのX Window Systemへの依存は、JDK 1.4で廃止される予定です。これによって、AWTではXサーバーを必要としなくなり、このトピックに説明されているXサーバーの構成手順も不要になります。ただし当面の間は、ボタンやタブ・バーのイメージが表示されない原因を知るため、このトピックを読み進めてXサーバーの構成について習得する必要があります。
ここでは、次の項目について説明します。
UNIXプラットフォームでは、通常、グラフィック・サポートはX Window Systemによって提供されます。X Window Systemは、現在はX.Orgという名称のUNIXベンダーのコンソーシアムで開発されたグラフィック・システムです。X Window Systemはネットワーク・グラフィック・システムです。グラフィック・リクエストは、Xクライアントと呼ばれるクライアント・アプリケーションから、Xサーバーと呼ばれるサーバー・プロセスに対して送信されます。XクライアントとXサーバーは、同じマシンで実行されていても、別々のマシンで実行されていても構いません。どちらの場合も、XクライアントとXサーバー間の通信は、Xプロトコルと呼ばれるネットワーク・プロトコルを使用して行われます。
UIX Dynamic Imagesでは、標準のJavaグラフィック・ライブラリであるAWTを使用して、すべてのグラフィック操作を実行します。AWTの現在の正式バージョン(Java 2リリース1.3)では、Xサーバーへのアクセスが必要です。つまり、UNIX上のJavaベースのアプリケーションからイメージを生成するためには、Xサーバーが必要で、AWTでその場所を認識している必要があります。ただし、これらの要件は近い将来なくなります。次のバージョンのJava(リリース1.4、現行ではベータ版)では、ヘッドレスJavaと呼ばれる機能を導入することでXサーバーへの依存は廃止されます。しかし現時点では、UNIXへのUIXのデプロイにおいてXサーバー・アクセスの設定は不可欠です。
Xサーバー・アクセスが正しく構成されていない場合でもUIXベースのアプリケーションは稼働しますが、イメージは生成されません。Xサーバーにアクセスできない場合、UIXではサーブレット・エンジンのエラー・ログ(JServの場合はjserv.log、OC4Jの場合はapplication.logなど)にエラー・メッセージを記録します。このメッセージにはしばしば次のようなスタック・トレースが含まれます。
uix/oracle.cabo.style: The following exception was thrown while
initializing the graphics environment:
uix/java.lang.InternalError: Can't connect to X11 window server using ':0.0'
as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at <UNLOADED Method>
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName0(Compiled Code)
at java.lang.Class.forName(Compiled Code)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:63)
at oracle.cabo.style.util.GraphicsUtils$GraphicsLoader.run(GraphicsUtils.java:294)
at java.lang.Thread.run(Thread.java:479)
uix/oracle.cabo.style: Could not initialize the graphical environment.
Please make sure that the DISPLAY environment variable is set correctly.
Proceeding with image generation disabled...
このエラー・メッセージは、Xサーバーへの接続が確立できなかったこと、および新しいイメージが1つも生成されないことを示しています。新しいイメージが必要でありながら生成できない場合は、可能なかぎり、UIXにより代替(ボタン・イメージのかわりにリンクや入力要素を表示するなど)のHTMLコンテンツが生成されます。
X Window SystemはほとんどのUNIXプラットフォームに標準で装備されていますが、Xサーバー・アクセスの設定に多少の構成作業が必要なことはよくあります。具体的には、Xサーバーが起動していること、AWTがXサーバーの場所を認識していること、およびXサーバーがAWTベースのアプリケーションにアクセスできるように構成されていることが必要です。これらの手順が1つでも正しく実行されていないと、イメージが表示されないか、代替のコンテンツで置き換えられ、前述したエラー・メッセージが表示される結果となります。このセクションでは、X Window Systemをサポートする環境でイメージ生成を可能にする方法について説明します。
ほとんどのUNIXプラットフォームに同梱される標準のXサーバー・ソフトウェアには、ホスト・マシンに求められるハードウェア要件があります。まず、Xサーバーでは、ハードウェア・フレーム・バッファへのアクセスを必要とします。また、キーボードがデフォルトで必要です(ただしキーボードがない場合でも解決方法はあります)。一般には、モニターおよびキーボードが付属したUNIXマシンであれば、Xサーバーは問題なく稼働します。しかし、中間層のデータ・センター環境にあるマシンにはフレーム・バッファおよびキーボードがインストールされていない場合があります。その場合はXサーバーを起動できないため、リモートXサーバー、XVFB、イメージ・サーブレット、または事前生成を使用するなどの解決方法を検討する必要があります。
Xサーバー・プロセスを開始する最も一般的な方法は、UNIXマシンのコンソールにログインする方法です。ほとんどのUNIXプラットフォームでは、簡単な認証アプリケーションであるX Display Managerが最初に起動し、ログイン画面が表示されます。ユーザーがログインすると、コンソール・ユーザーの所有プロセスとしてXサーバーが開始されます。一般的なデフォルトの構成では、コンソール・ユーザーがXサーバーを所有し、他のユーザーがXサーバーにアクセスすることはできません。後述しますが、このようなデフォルト設定は、Xサーバーへのアクセス範囲を広げるように上書きできます。
システム管理がリモートで実行されている場合(リモート・マシンからTelnetを使用して管理している場合など)、コンソールの所有者がリモート管理者にかわってXサーバーを起動することが必要な場合があります。Xサーバーがすでに稼働しているかどうかを判断するには、Xで始まるプロセス名があるかどうかをチェックします。たとえばSolarisの場合、Xサーバー・プロセスはXsunという名前です。
Xサーバーの稼働中、クライアント・アプリケーションが1つでも接続されている間は、Xサーバーを停止しないことが大変重要です。Xサーバーが停止されると、接続されているクライアントに信号が送られます。この通知を受け取ると、AWTではJava Virtual Machineを強制終了し、アプリケーションも強制終了されます。
AWTでXサーバーに接続後、Java Virtual Machineの稼働中はAWTによって接続が維持されることが、この問題をより複雑にしています。つまり、一度イメージが生成されると、Xサーバーとの接続が確立され、サーブレット・エンジンが停止するまで接続は維持されます。コンソール・ユーザーがログアウトするとX Display ManagerではXサーバーをシャットダウンするため、管理者は、アプリケーションの実行中はXサーバーのホスト・マシンにログインしている必要があります。セキュリティのためにコンソールを(たとえばxlockなどのツールを使用して)ロックすることは可能ですが、コンソール・ユーザーがログアウトしてXサーバー・セッションを終了しないようにしてください。
注意: コンソール・ログインなしでXサーバーを起動するよう、Xサーバーのホスト・マシンを構成することもできます。また、XVFB擬似XサーバーをX Display Managerとは無関係に使用する方法もあります。ただしどの場合も、AWTによって接続が確立された後は、Xサーバーを停止しないことが重要です。
Xサーバーの起動後に行う構成プロセスの手順は、DISPLAY環境変数を使用してXサーバーの場所を指定することです。すべてのXクライアント・アプリケーションでは、DISPLAY環境変数で指定された情報を使用して、Xサーバーの検索方法および接続方法を決定します。DISPLAY環境変数では次の3つの情報を指定します。
0
(ゼロ)に設定します。
0
(ゼロ)が使用されます。
<machine name>:<server number>.<screen number>
XサーバーがXクライアントと同じマシン上で稼働している場合、最も簡単なDISPLAYの設定方法は、マシン名と画面番号を2つともデフォルトにすることです。そのためには、DISPLAYを:0
とだけ設定し、ローカル・マシン上のサーバー0(ゼロ)の画面0(ゼロ)がすべてのX接続に使用されるようにします。これは:0.0
と指定されることもありますが、画面番号は必ずしも明示的に指定する必要はありません。
通常、DISPLAY環境変数はログイン・スクリプトまたはシェル・スクリプトで指定できます。しかし一部のサーブレット環境では、サーブレット・エンジン専用の構成ファイルでDISPLAY環境変数を指定する必要があります。たとえば、Apache JServ内で自動モードで実行している場合には、jserv.propertiesファイルに次の構文でDISPLAY環境変数を指定します。
wrapper.env=DISPLAY=<machine name>:<server number>.<screen number>
DISPLAY環境変数が正しいサーブレット・エンジン構成ファイルに明示的に設定されていない場合、Xサーバーへの接続に失敗し、イメージ生成を使用できない可能性があります。
X Window Systemはネットワーク・ベースの操作向けに設計されているため、Xクライアントとは別のマシンでXサーバーを実行できます。この機能は、Xサーバーをローカルに実行するための中間層マシンを用意できないような、ヘッドレスな中間層環境で役に立ちます。この場合、Xサーバーをサポート可能な他のマシン上でXサーバーを実行できます。リモートのXサーバーへは、DISPLAY環境変数でマシン名を指定するだけで、Xクライアントからアクセスできます。
ただし、ヘッドレスな中間層環境内で、1台のリモートXサーバーを複数のマシンに対するDISPLAYとして使用することは、多少危険です。前述のように、なんらかの理由でXサーバーが停止した場合、接続されているプロセスはすべて強制終了されるためです。この単一の障害箇所を回避するには、UIXベースのアプリケーションをXサーバーの停止から保護する、リモートのイメージ・サーブレット・インスタンスを使用します。
DISPLAYの設定後に行う構成プロセスの手順は、XクライアントからXサーバーにアクセスできるかどうかの検証です。Xサーバー・アクセスを検証する最も簡単な方法は、X Window Systemに同梱されているxtermやxclockなど、多くのXクライアント・アプリケーションのいずれか1つを実行することです。(Solarisの場合、これらのツールは/usr/openwin/binディレクトリにあります。)
DISPLAY環境変数が正しく設定されていれば、xtermやxclockなどのアプリケーションは問題なく実行され、エラー・メッセージは表示されません。DISPLAYがローカル・マシンに設定されている場合、アプリケーションはコンソールに表示されます。DISPLAYが設定されていないか、または正しく設定されていない場合、「Can't open display: ...」などのエラー・メッセージが出力されます。DISPLAYが正しく設定されていても、クライアントがXサーバーへのアクセスを許可されていない場合、次のような詳細なエラー・メッセージが表示されます。
Xlib: connection to "..." refused by server
Xlib: Client is not authorized to connect to Server
Xt error: Can't open display: ...
アクセス制御の問題は、xhostまたはxauthのいずれかの、X Window Systemのセキュリティ・メカニズムを使用して解決できます。
Xサーバー・アクセスはユーザー単位で制御可能なため、コマンドラインからXサーバー・アクセスをテストする場合、サーブレット・エンジンの実行に使用されているIDと同じユーザーIDを使用することが重要です。Webサーバー・プロセスおよびサーブレット・エンジン・プロセスは、apache
またはoracle
などの特別なユーザーIDで実行されることがよくあります。サーブレット・エンジン環境からXサーバー・アクセスをテストする前に、該当するユーザーが実際にXサーバーへのアクセスを許可されているかどうかを確認することが重要です。これをテストする最も簡単な方法は、サーブレット・エンジンの実行に使用されているユーザーIDでログインし、コマンドラインから標準のXクライアント・アプリケーションの1つを実行してXサーバー・アクセスをテストする方法です。通常、コンソールの所有者がサーブレット・エンジン・プロセスの所有者と異なる場合、Xサーバーへのアクセスはデフォルトではコンソール所有者にしか許可されていないため、(xhostまたはxauthを使用した)いくつかのアクセス制御構成が必要です。
コマンドラインからXクライアント・アプリケーションを実行してXサーバー・アクセスを確認した後、サーブレット・エンジンからのXサーバー・アクセスをテストする必要があります。AWTを1回コールするだけで、AWTがXサーバーとの接続を確立するため、Xサーバー・アクセスをテストするサーブレットまたはJavaServer Pages(JSP)の記述は簡単です。次のサーブレットでjava.awtGraphicsEnvironment.getLocalGraphicsEnvironment()
をコールすると、AWTではXサーバーに接続します。
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class TestServlet extends HttpServlet
{
public void service(
HttpServletRequest request,
HttpServletResponse response
) throws ServletException, IOException
{
// This code will force AWT to connect to the X server
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment();
// Set the content type
response.setContentType("text/html");
// Get the writer
PrintWriter out = response.getWriter();
// Send some content
out.println("<html><body><h1>Hello, world!</h1></body></html>");
}
}
次のJSPでも同じ結果が得られます。
<% java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(); %>
<html>
<body>
<h1>Hello, world!</h1>
</body>
</html>
サーブレット・エンジン内からXサーバー接続をテストする前に、DISPLAY環境変数が適切なサーブレット・エンジン構成ファイルに設定されていることを確認してください。
Xサーバー接続が確立されると、getLocalGraphicsEnvironment()
が返され、「Hello, world!」というメッセージがブラウザに送信されます。Xサーバー接続を確立できない場合、何種類かあるエラー・メッセージの1つが表示されます。
DISPLAY環境変数がまったく設定されていない場合、AWTではNoClassDefFoundError
をレポートすることがあります。
java.lang.NoClassDefFoundError: sun/awt/X11GraphicsEnvironment
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName0(Compiled Code)
at java.lang.Class.forName(Compiled Code)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:63)
at TestServlet.service(TestServlet.java:16)
ただし、このエラー・メッセージは誤解を招く場合があります。このメッセージは実際にはクラスをロードする際の問題によって出力されたものではありません。このエラーは、該当する構成ファイルにDISPLAY環境変数を設定することで回避できます。
もう1つの代表的なエラー・メッセージは、DISPLAYが指定されていながら、指定したXサーバーにアクセスできない場合に表示されます。
Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at <UNLOADED Method>
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:124)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:63)
at TestServlet.service(TestServlet.java:16)
xtermなどのコマンドライン・ツールでXサーバーにアクセスできても、同じユーザーがサーブレット・エンジン内で実行するとアクセスできない場合、問題は後述するxauthの構成にあると考えられます。
X Window Systemには、2つのセキュリティ・メカニズムが組み込まれています。xhostツールは、マシン・レベルのセキュリティ制御に使用します。xauthツールは、ユーザー・レベルのセキュリティ制御に使用します。ほとんどの構成では、xhostを使用して特定のマシンからXサーバーへのアクセスを許可するだけで十分です。
Xサーバーが最初に起動された時点では、アクセスは通常、ローカル・マシンのコンソール・ユーザーに限定されています。その他のユーザー(Telnetでローカル・マシンにログインする管理者など)、またはコンソール所有者が使用する他のユーザーID(apache
やoracle
など)でも、デフォルトではXサーバーにアクセスできません。
Xサーバーへのアクセスを許可する最も簡単な方法は、xhostを使用してローカル・マシン上のユーザーすべてのアクセスを許可する方法です。たとえば、管理者が管理者のユーザーIDを使用してXサーバー・コンソールにログインし、別のユーザーIDを使用して同じマシン上でサーブレット・エンジンを実行するには、次のコマンドで同じマシン上のすべてのユーザーにアクセスを許可します。
xhost + <machine name>
ここで、<machine name>はXサーバーおよびサーブレット・エンジンの両方が稼働しているローカル・マシンの名前です。このコマンドを実行すると、このマシンに(コンソール、Telnet、リモート・ログインなどで)ログインしているユーザーすべてのXサーバーへのアクセスが許可されます。
xhostツールを使用して、リモート・マシン上のすべてのユーザーにアクセスを許可することもできます。たとえば、サーブレット・エンジンはmtierという名前のマシン上で、Xサーバーはxservという名前のマシン上でそれぞれ稼働している場合、mtier上で稼働しているサーブレット・エンジンへのアクセスを許可するには、xserv上のコンソール・ユーザーは次のようなコマンドを実行する必要があります。
xhost + mtier
xhostでは、xhost +
というコマンドですべてのアクセス制御を無効にすることもできます。このコマンドを実行すると、ネットワーク上の全マシンのユーザーすべてにアクセスが許可されます。ただし、この方法でアクセス制御を無効にすると安全性が低くなるため、このコマンドの使用は避け、マシンごとにアクセスを許可するようにしてください。
注意: Xサーバーを再起動すると、xhostのアクセス制御はデフォルトの状態にリセットされます。つまり、Xサーバーを再起動すると、前のセッションでxhostを使用して広範囲のユーザーにアクセスを許可していたとしても、Xサーバーにアクセスできるのはコンソール・ユーザーのみになります。このため、Xサーバーを再起動するたびに適切なxhostコマンドを実行する必要があります。
xhost + <local machine name>
を実行してXサーバーへのアクセスを許可する方法は非常に簡単ですが、xhostはマシン・レベルでアクセスを許可するため、実際の必要範囲よりも広い範囲にアクセスが許可されます。xauthツールでは、特定のユーザーにアクセスを許可できます。たとえば、xauthを使用して、同じマシン上の他のユーザーにアクセスを許可せずに、サーブレット・エンジンの実行に使用されている特定のユーザーIDに対してのみアクセスを許可できます。
xauthのセキュリティ・メカニズムでは、内部的にCookieが権限のあるユーザーの識別に使用されます。Xサーバーが起動すると、このCookieが確定され、コンソール・ユーザーのホーム・ディレクトリにある .Xauthorityファイルに書き込まれます。このCookieを知っているユーザーのみがXサーバーにアクセスできます。つまりデフォルトでは、コンソール・ユーザーのみがXサーバーにアクセスできることになります。
実際には、.Xauthorityファイルに現在のCookieが記録されていても、コンソール・ユーザーに対してアクセスが拒否される場合があります。一部のサーブレット・エンジンで実行中の場合、ユーザーの .Xauthorityファイルが検索できないことがあります。その場合、Xサーバーの所有者でも、サーブレット・エンジン内からXサーバーにアクセスできません。たとえば、自動モードでJServを実行している場合、Xサーバーへのアクセスはコンソール・ユーザーに対しても拒否されます。この問題を回避するには、XAUTHORITY環境変数を使用して .Xauthorityファイルを明示的に識別する必要があります。JServがコンソール・ユーザーによって実行されているにもかかわらずXサーバーへのアクセスが拒否された場合、jserv.propertiesに次の行を追加するとアクセスが可能になります。
wrapper.env=XAUTHORITY=~/.Xauthority
Xサーバーの所有者以外のユーザーにアクセスを許可するには、xauthツールを使用してこのユーザーに対する .Xauthorityファイルを作成する必要があります。たとえば、ユーザーadministrator
がコンソールにログインしていて、ユーザーapache
が同じマシン上のサーブレット・エンジンの実行に使用されている場合、apache
にアクセスを許可するには次の手順を実行します。
administrator
でxauthツール(xauth
)を実行します。
xauth>
というプロンプトに対し、list
と入力してすべてのCookieをリスト表示します。
machine name:0 MIT-MAGIC-COOKIE-1 34285439adcas098q2w3098qf3209412
これが、<machine name>:0
で稼働しているXサーバーに対するxauth Cookieです。
apache
でxauthツールを実行します。
xauth>
というプロンプトに対し、add
コマンドでこのCookieを追加します。
xauth> add machine name:0 MIT-MAGIC-COOKIE-1 34285439adcas098q2w3098qf3209412
list
ですべてのCookieを表示します。
exit
と入力し、変更内容を保存してxauthツールを終了します。 この結果、現行のxauth Cookieを記録した .Xauthorityファイルが、ユーザーapache
のホーム・ディレクトリに作成されます。これで、ユーザーapache
はXサーバーにアクセスできるようになります。
注意: 通常、xauth Cookieは、Xサーバーが起動されるたびに変更されます。Xサーバーを起動するたびに前述の手順を繰り返す必要があるため、UNIXのシェル・スクリプトを使用して自動化することをお薦めします。同じような手順で、リモート・マシン上の特定のユーザーにアクセスを許可することができます。リモート・ユーザーにxauthアクセスを許可する方法、およびこの手順を自動化する方法の詳細は、xauthのmanページおよびWebサイトを参照してください。
マシンの中には、Xサーバーを実行するために必要なハードウェア要件を満たさないものもあります。データ・センターをホストとする中間層マシンの場合、フレーム・バッファやキーボードがないのは珍しいことではありません。この場合、各中間層マシン上でXサーバーをローカルに実行することはできません。かわりに、ハードウェア要件を満たすマシン上でリモートにXサーバーを実行できます。しかし、何台ものヘッドレス・マシンで1台のリモートXサーバーを共有するような構成は、共有されるXサーバーで問題があった場合にすべてのマシンが影響を受けるため、リスクの高い構成といえます。
リモートXサーバーにかわる手段として、X Virtual Frame Buffer(XVFB)などの擬似Xサーバーを実行する方法があります。XVFBは一種のXサーバーです。XVFBはX Window Systemのリクエストを処理し、標準のXサーバーと同じネットワーク・プロトコルを使用してレスポンスを送信します。XVFBと標準のXサーバー・ソフトウェアとの主な違いは、XVFBではハードウェアのフレーム・バッファではなくメモリー内の仮想フレーム・バッファを使用する点です。このためXVFBは、ハードウェア・フレーム・バッファとキーボードのないヘッドレスな中間層マシンを含む、ほとんどのUNIXマシンで実行可能です。
1台のXサーバーを共有するかわりに各ヘッドレス中間層マシンでXVFBを実行する利点は、XVFBに障害が発生してもローカル・マシンで稼働中のアプリケーションにしか影響しない点です。イメージ・サーブレットとともに使用すれば、XサーバーやXVFBのあらゆる障害による問題を隔離して、Webアプリケーションの操作にほとんど影響しないようにできます。
XVFBはX Window Systemに標準で装備されており、X.Orgが開発および配布を行っています。X.Orgは、ほとんどのUNIXベンダーを含むX.Orgメンバーに、ソース・コード形式でX Window Systemを配布しています。UNIXベンダーは、プラットフォーム固有のX Window Systemバイナリをビルドして配布します。これらのバイナリは、ベンダーによって、プラットフォーム固有のオペレーティング・システムに同梱されます。ただし、XVFBバイナリを配布していないUNIXベンダーもあります。Compaq社や多数のLinuxベンダーでは、XVFBを標準のオペレーティング・システム・コンポーネントに含めています。HP社などのUNIXベンダーでは、Webサイトを通じてXVFBバイナリを提供しています。Sun社などのUNIXベンダーでは、XVFBバイナリを一切配布していません。
UNIXベンダーによってXVFBバイナリが提供されていないプラットフォームの場合、X.Orgのソース・コードからXVFBバイナリをビルドする必要があります。
XVFBバイナリのビルドは、特に難しい作業ではありません。次の手順は、Solaris 8にXVFBをビルドする方法を示しています。
XVFBのソース・コードはX.OrgのFTPサーバーから入手できます。X Window Systemのソース・コードは、いくつものtarファイルで配布されています。このうち、XVFBのビルドに必要なのは最初のtarファイルのみです。X11R6.5.1用に必要なtarファイルは、次のアドレスからダウンロードできます。
ftp://ftp.x.org/pub/R6.5.1/tars/xorg-1.tar.gz
このtarファイルを、XVFBをビルドするマシンにダウンロードして解凍、展開します。(X.Orgの以前の名称であるX Consortiumに由来する)xc
という名前のディレクトリが最上位レベルに作成されます。
ビルドのための構成情報は、xc/config/cf/ディレクトリの下にあるsite.defファイルに指定されています。このファイルを、XVFBのビルドを指示する内容に編集する必要があります。また、すべてのX Window Systemをビルドする必要はないため、ビルドの処理速度向上のためにsite.defファイル内の多くの項目をコメント・アウトできます。Solarisの場合は最後に、ProjectRoot
を、Solarisで通常X関連ファイルが格納される/usr/openwinに変更します。
最後に、XVFBバイナリをビルドします。この作業には、次のソフトウェアが必要です。
XVFBをビルドする準備ができたら、xcディレクトリに移動して次のコマンドを実行します。
make World
ビルド(約1時間)が完了すると、XVFB実行可能ファイルがxc/programs/Xserver/Xvfbに作成されます。
XVFB実行可能ファイルが正常かどうかをチェックするには、ldd Xvfb
を実行してリンクが成功していることを確認します。問題がなければ、次のような内容が表示されます。
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1
XVFBを起動するには、次のコマンドラインを使用します。
Xvfb :1 -screen 0 1x1x24
XVFBバイナリがルートとして実行されるか、またはSUIDビットが設定されている必要があります。引数:1
は、XVFBバイナリがサーバー番号1(標準のXサーバーは通常サーバー番号0として稼働)として稼働することを示しています。-screen
引数は、サイズが1×1で24ビット・ピクセルのスクリーンを1つ使用することを示しています。イメージはすべてスクリーン表示されることなく生成されるため、1×1というスクリーン・サイズで十分です。
XVFBは、アプリケーションの存続期間中は稼働している必要があるため、マシンの起動プロセスでXVFBを自動的に起動することをお薦めします。起動されたXVFBは、マシンがシャットダウンされるまでバックグラウンド・プロセスとして稼働し続けます。
XVFB実行可能ファイルが稼働しているときには、クライアント・アプリケーションはDISPLAY環境変数を:1
に設定することでXVFBに接続できます。:1
という設定は、すべてのXグラフィック操作でローカル・マシン上のサーバー番号1(XVFBサーバー)を使用することを示しています。JServで実行中の場合は、DISPLAY環境変数はjserv.propertiesに次のように設定します。
wrapper.env=DISPLAY=:1
XVFBの起動時に、次のエラー・メッセージが表示される場合があります。
error opening security policy file /usr/openwin/lib/X11/xserver/SecurityPolicy
このメッセージが表示されないようにするには、XVFBの起動時に-sp
引数を使用してセキュリティ・ポリシー・ファイルの場所を明示的に指定します。Solarisの場合、セキュリティ・ポリシー・ファイルは/usr/openwin/server/etc/SecurityPolicyにあります。したがって、XVFBが必ずセキュリティ・ポリシー・ファイルを読み込むようにするには、次のコマンドラインを使用できます。
Xvfb :1 -screen 0 1x1x24 -sp /usr/openwin/server/etc/SecurityPolicy
ただし、デフォルトでは、セキュリティ・ポリシー・ファイルが見つからない場合でも、XVFBで許可するのはローカル・クライアントのアクセスのみです。
XVFBが稼働するためには、fixedフォントの場所を特定できる必要があります。デフォルトでは、XVFBバイナリは/usr/openwin/lib/X11/fonts/misc/の下のフォント・ディレクトリでフォントを検索します。このディレクトリが存在しないか、またはあってもfixedフォントがインストールされていない場合、「could not open default font 'fixed'」というエラーが表示されてXVFBは起動しません。
fixedフォントは、X Window Systemに標準で含まれています。ターゲット・マシンにfixedフォントがインストールされていない場合、別のSolarisマシンからコピーするか、またはX.Orgから入手して、インストールする必要があります。fixedフォントが/usr/openwin/lib/X11/fonts/misc/以外の場所にインストールされている場合、-fp
コマンドライン引数を使用して、XVFBで使用されるフォント・パスが正しい場所を示すように変更します。
これまでに説明したイメージ生成の解決方法では、いずれもWebアプリケーションがAWTを介して直接Xサーバーに接続する必要がありました。前述したように、この直接的な接続方法の欠点の1つは、アプリケーションの実行中はどのような理由であれXサーバー(またはXVFBプロセス)をシャットダウンできない点です。Xサーバーが停止すると接続されているアプリケーションはすべて強制終了されます。このような状況が発生しないようにする必要があります。
UIX Dynamic Imagesには、Xサーバーの障害からアプリケーションを保護するソリューション、イメージ・サーブレットが用意されています。イメージ・サーブレットでは、UIXアプリケーションからHTTP経由で送られるイメージ生成リクエストを処理します。リクエストを受け取ると、可能な場合、イメージ・サーブレットはイメージを生成し、HTTP経由でそのイメージのストリームを行います。生成されたイメージは、その後ローカルのUIX Dynamic Imagesキャッシュに保存され、必要に応じてエンド・ユーザーに提供されます。
イメージ・サーブレットはすべての通信をHTTP経由で行うため、そのインスタンスはネットワークからアクセス可能なマシン上のどのサーブレット・エンジンで稼働していても構いません。したがって、たとえばWindowsマシンにイメージ・サーブレットをデプロイし、ヘッドレスなUNIXマシン用のイメージ生成に使用できます。この場合、イメージ生成にWindowsプラットフォームで提供されるグラフィック・サポートで十分行えるため、Xサーバーは必要ありません。
イメージ・サーブレットをUNIXマシンにデプロイする場合は、イメージ・サーブレットがXサーバー(またはXVFB)にアクセスできることが必要です。ただし、グラフィック関連の操作はすべてイメージ・サーブレットが行うため、Webアプリケーション自体で直接Xサーバーと接続する必要はなくなります。かわりに、WebアプリケーションはHTTP経由でイメージ・サーブレットと通信し、間接的にXサーバーと接続することになります。この構成の利点は、WebアプリケーションがXサーバーの障害から保護されることです。WebアプリケーションがXサーバーに直接接続されている場合、Xサーバーに障害が発生するとWebアプリケーションは強制終了されます。一方、イメージ・サーブレットがWebアプリケーションのかわりにXサーバーと接続している場合、Xサーバーに障害が発生するとイメージ・サーブレットは強制終了されますが、Webアプリケーションの機能は継続します(ただしイメージ生成はできなくなります)。
イメージ・サーブレットは、任意のサーブレット・エンジンにデプロイ可能なHTTPサーブレットです。イメージ・サーブレットのクラスはoracle.cabo.image.servlet.ImageServlet
です。サーブレット初期化パラメータは必要ありません。UIX JARファイルと依存するその他のファイルをクラスパスに配置し、任意のサーブレット・エンジンにサーブレットをインストールするだけです。
「インストール」のトピックに、UIXベースのWebアプリケーションを様々なサーブレット・エンジン環境にインストールする手順が詳細に説明されています。イメージ・サーブレットのインストール方法は、UIXアプリケーションのインストール方法と非常によく似ています。主な違いは次のとおりです。
oracle.cabo.servlet.BajaServlet
ではなくoracle.cabo.image.servlet.ImageServlet
です。イメージ・サーブレットをインストールするには、これらの点に留意して、「インストール」のトピックの手順に従ってください。
イメージ・サーブレットの稼働を確認後、Webブラウザでイメージ・サーブレットを指定してイメージ生成の準備ができているかどうかを確認します。たとえば、イメージ・サーブレットがhttp://localhost:8888/image/servletにバインドされている場合、WebブラウザからこのURLにアクセスがあると、診断メッセージが表示されます。
イメージ・サーブレットのデプロイ完了後、使用するイメージ・サーブレットの場所をUIXに通知する必要があります。これにはuix-config.xml
ファイル内の1つのエントリのみが必要です。
<?xml version="1.0" encoding="ISO-8859-1"?>
<configurations xmlns="http://xmlns.oracle.com/uix/config">
<default-configuration>
<image-servlet-url>http://www.example.org:8888/image/servlet</image-servlet-url>
</default-configuration>
</configurations>
uix-config.xml
の詳細は、「構成」のトピックを参照してください。
Javaコード内でこれを管理する必要がある場合、イメージ・サーブレットの場所は、Configuration.IMAGE_SERVLET_URL
プロパティでjava.net.URL
として指定します。たとえば、次のコードでは、デフォルトのConfiguration
インスタンスにURLを設定します。
URL servletURL = null;
try
{
servletURL = new URL("http://localhost:8888/image/servlet");
}
catch (MalformedURLException e)
{
}
ConfigurationImpl config = ConfigurationImpl.sharedInstance();
config.putProperty(config.IMAGE_SERVLET_URL, servletURL);
「構成」のトピックで説明したように、ほとんどのアプリケーションで、専用のConfiguration
インスタンスを作成して登録する必要があります。
イメージ・サーブレットが稼働中でイメージ・サーブレットへのURLが指定されていれば、UIX Dynamic Imagesにより、すべてのイメージ生成リクエストが指定のサーブレットに自動的にリダイレクトされます。
場合によっては、Xサーバー、XVFB、またはイメージ・サーブレットの構成に費やした労力に見合う効果が得られないことがあります。このような場合、UIX Dynamic Imagesにはもう1つの方法があります。アプリケーションで使用されるイメージを事前に生成し、アプリケーションにバンドルする方法です。
UIX Dynamic Imagesでは、イメージを生成する際に、イメージおよびイメージを記述したメタデータ・ファイルの両方を、ファイル・システム上のイメージ・キャッシュに保存します。次に同じイメージがリクエストされた際、UIX Dynamic Imagesにはそのイメージが生成済であるという情報があるため、同じイメージを何度も生成しないですみます。イメージを記述したメタデータがイメージとともに保存されるため、サーブレット・エンジンのセッション間でイメージを再利用したり、マシン間でイメージをコピーすることが可能です。
デフォルトでは、すべてのイメージおよびイメージのメタデータ・ファイルは、Webサーバーまたはサーブレット・コンテキストのルート・ディレクトリの/cabo/images/cache
ディレクトリに保存されます。アプリケーションを実行すると、このディレクトリにイメージが保存されていきます。アプリケーションのあらゆる機能を実行した後には、アプリケーションに必要なイメージがすべて生成されています。このキャッシュ・ディレクトリをアプリケーションに同梱すれば、デプロイ環境での動的イメージ生成、およびそれに関連した構成作業を行う必要がありません。
アプリケーションによっては、すべてのイメージを事前に生成できない場合もあります。たとえば、カスタマイズが可能なアプリケーションの場合、特定のユーザーが必要とするイメージをすべて予測することは困難です。また、サポートされているすべての言語に対するイメージの生成は、単調で時間のかかる作業です。しかし、多くのアプリケーションでは、少なくとも一部の言語に対して事前生成のイメージを提供して、ユーザーによるデプロイ作業を大幅に単純化できます。このため、JDK 1.4でXサーバーの構成が不要になるまでは、イメージを事前生成することは良い選択だと言えるでしょう。
ここでは、すべてのアプリケーション開発者に対する推奨事項を説明します。
可能なかぎり、事前に生成したイメージのキャッシュを同梱し、デプロイ・プロセスを単純化することをお薦めします。UIX Dynamic Imagesでは、Xサーバーにアクセスせずに事前生成イメージを提供することが可能なため、できるだけ多くの事前生成イメージを同梱することによってアプリケーションを即座に最大限に利用できます。事前生成イメージが十分に提供されている場合には、Xサーバーの構成がまったく必要ないこともあります。
事前生成イメージを取得する最も簡単な方法は、アプリケーションのリグレッション・テスト時に生成されるイメージを収集する方法です。
イメージ・サーブレットは、多くのデプロイ環境で役立つ柔軟性を提供します。また、イメージ・サーブレットを使用することでWebアプリケーションはXサーバーから切り離され、より安定した構成が提供されます。このため、構成担当者が、イメージ・サーブレットの使用の可否を選択できる必要があります。
UIX Controllerベースのアプリケーションの場合、構成担当者はoracle.cabo.image.servletURL
初期化パラメータでイメージ・サーブレットのURLを設定できます。ただしその他のアプリケーションの場合は、Configuration
APIを使用して、プログラムでイメージ・サーブレットのURLを指定する必要があります。UIXアプリケーションの開発者は、デプロイ環境に固有のイメージ・サーブレットのURLを、ユーザーが指定できるようなメカニズムを公開することをお薦めします。サーブレットの場合は、サーブレット初期化パラメータを使用するメカニズムが適切です。oracle.cabo.image.servletURL
パラメータ名は、この目的で再利用できます。