Posts filed under ‘未分類’
友人の結婚式と桜
先週の土曜日に、友人の結婚式がありました。彼とは前の部署にいた時に知り合い、私の結婚式にも来てくれたり入社以来とても仲良くさせて頂いている大切な友人の一人です。彼の結婚を祝福するように天気にも恵まれとても素晴らしい結婚式でした。披露宴が終わった後、二次会まで少し時間があったので、友人と共に千鳥ヶ淵を少し散歩してきました。桜も満開でとても多くの人でにぎわっていました。
このような良い日に結婚式があげられて本当に良かったですね。末永くお幸せに！！
週末の散歩ー上野不忍池
先週の土曜日に散歩がてら、上野の不忍池に行ってきました。東京に来て 18 年程経ちますが、上野の不忍池に行ったのは今回が初めてでした。とても多くの方々が花見に来られていて驚いたのですが、そういった集まっている人達や桜を見ながら 2 時間程散歩をしてきました。それにしてもまだまだ本当に寒いですよね、昨日もそうでしたが、昼間でも真冬のジャケットを着て問題ない位です。花見シーズンに入ってきましたがまだまだ寒いのでくれぐれも風邪を引かないよう、体調には気をつけてください。
Servlet 3.0 web-fragment.xml による設定
Web アプリケーションの開発者は Apache Wicket や Spring 等 Servlet とは異なる別の外部フレームワークを開発時に利用する事があるかと思います。これらの外部フレームワークを使用するためには、これらのフレームワーク特有の設定 (Servlet, Filter 等)を web.xml に設定する必要があります。しかし複数の外部フレームワークを同一アプリケーション内で使用する場合、単一の web.xml ファイル内に全ての設定が含まれファイルが肥大化します。また web.xml ファイルが肥大化すると、各フレームワーク毎の設定を管理する際に可読性も低下しているため、管理が困難となります。
そこで、Web Fragment はフレームワーク毎に独自に設定を登録、管理できるようなメカニズムを提供しています。このWeb Fragment は Servlet 3.0 に導入された新しい技術で、配備記述子をモジュール化し、コンテナがモジュール化した配備記述子を認識する事ができるようになり、上記のような問題を解決しています。
一つの、web-fragment.xml ファイルは web.xml の一部として認識され、利用する外部フレームワーク毎に複数の web-fragment.xml を作成することもできます。
それでは、web-fragment.xml をどこに作成するか確認してみましょう。まず、Web アプリケーションのプロジェクトを作成します。この際、WEB-INF/lib ディレクトリ配下に、web-fragment.xml を含む jar ファイル (下記の例ではExternalLib.jar) をコピーします。
| > jar tvf FragmentSample.war 0 Sun Mar 14 14:36:00 JST 2010 META-INF/ 95 Sun Mar 14 14:35:58 JST 2010 META-INF/MANIFEST.MF 0 Sun Mar 14 14:36:00 JST 2010 WEB-INF/ 0 Sun Mar 14 14:36:00 JST 2010 WEB-INF/classes/ 0 Sun Mar 14 14:36:00 JST 2010 WEB-INF/lib/ 2076 Sun Mar 14 14:36:00 JST 2010 WEB-INF/lib/ExternalLib.jar 515 Sun Mar 14 14:36:00 JST 2010 WEB-INF/sun-web.xml 469 Sun Mar 14 14:36:00 JST 2010 index.xhtml |
ExternalLib.jar には、META-INF ディレクトリ配下に web-fragment.xml を作成します。
| > jar tvf ExternalLib.jar 0 Sun Mar 14 14:36:00 JST 2010 META-INF/ 109 Sun Mar 14 14:35:58 JST 2010 META-INF/MANIFEST.MF 995 Sun Mar 14 14:36:00 JST 2010 META-INF/web-fragment.xml |
web-fragment.xml には下記のような内容を記載します。下記の例では JSF 2.0 の設定を web-fragment.xml に記載していますが、web.xml に記載する内容とほぼ同様の内容が記載されている事が分かります。
| <?xml version=”1.0″ encoding=”UTF-8″?> <web-fragment xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd” version=”3.0″> <context-param> <param-name>javax.faces.PROJECT_STAGE</param-name> <param-value>Development</param-value> </context-param> <servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>/faces/*</url-pattern> </servlet-mapping> <session-config> <session-timeout> 30 </session-timeout> </session-config> <welcome-file-list> <welcome-file>faces/index.xhtml</welcome-file> </welcome-file-list> </web-fragment> |
web.xml の記載は、Servlet 3.0 からオプション化されていますので、web.xml が無くても上記は動作しますが、web.xml を記載する場合は、<metadata-complete> に true が設定されていないことを確認してください。この<metadata-complete> はアノテーションの利用を許可したり、外部リソースをコンテナが自動的に検出するかどうかを指定する設定ですが、true に設定されていると、アノテーションの利用が不可になる他、web-fragment.xml 等のリソースの自動検出ができなくなります。このタグが記述されていない場合、もしくは false に設定されている場合は、アノテーションも、リソースの自動検出も有効になりますので確認してください。
| <web-app version=”3.0″ xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd” metadata-complete=”false”> |
また、複数の外部フレームを利用する場合、フレームワーク毎にそれぞれの web-fragment.xml を作成する事もできます。また、設定を読み込む順番を指定するため２種類の方法を提供しています。
● Absolute Ordering
web.xml ファイルに、<absolute-ordering> を指定して順番を設定します。
● Relative Ordering
web-fragment.xml ファイルに <ordering> を指定して順番を設定します。
例えば、２つの外部フレームワークを２つの Web Fragment(Fragment1, Fragment2) にそれぞれ設定した場合を想定します。この時、web.xml に順番を指定する場合、下記のように記載します。web.xml の設定が最初に読み込まれた後、Fragment2→Fragment1の設定が読み込まれます。
| <web-app> <name>MyApp</name> <absolute-ordering> <name>Fragment2</name> <name>Fragment1</name> </absolute-ordering> … </web-app> |
最後に、web-fragment.xml の設定は外部フレームワークやリソースをモジュール化して読み込ませる事が可能になる他、web.xml の肥大化を防ぎ、可読性も向上するため設定管理が楽になります。是非お試しください。
| 備考： 最初は、上記 web-fragment.xml の設定を Wicket 1.4 を使用して試しましたが動作させる事ができませんでした。調査した結果、現在の Wicket 1.4 は WicketFilter 中で web.xml ファイルを直接参照するように実装されているため、web-fragment.xml の設定ファイル中から設定を読み込む事ができないためでした。今後 WicketFilter 側で修正が施されれば、Wicket の設定も web-fragment.xml に含める事ができるようになるかもしれません。 実装部分： |
Servlet 3.0 File Upload 機能
Servlet 3.0 ではマルチパートデータを扱う事ができるようになったため、とても簡単にファイルアップロード機能を実現できます。
(表示用 HTML)
| <html> <head> <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″> <title>JSP Page</title> </head> <body> <FORM action=”/FileUpload/MyFileUpload” enctype=”multipart/form-data” method=”POST”> アップロードするファイル名: <INPUT type=”file” name=”content”> <INPUT type=”submit” value=”Submit”> </FORM> </body> </html> |
アップロードしたファイル名を取得するためには、getFilename() メソッドで実装しているように、ヘッダ：Content-Disposition の内容を取得しファイル名を抽出します。Content-Disposition ヘッダは下記のような値を含みますので、filename の部分を取得します。
| Content-Disposition: form-data; name=”content”; filename=”FILE_NAME” |
また、@MultipartConfig のアノテーションを使用して、アップロードするファイルの上限や、配置場所等を設定します。
| import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.annotation.MultipartConfig; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.Part; @WebServlet(name=”MyFileUpload”, urlPatterns={“/MyFileUpload”}) @Override private String getFilename(Part part) { |
簡単なメモ書き程度ですが、簡単にファイルアップロード機能を実装できる事が
お分かり頂けるかと思います。
本当は、Async Servlet を使って時間のかかるアップロード処理を非同期で
実現するコードも紹介したいのですが、一部動作がおかしく調査中ですので、
後日うまくいけば、ここに追記します。
今日も関東地方は雪
関東地方は朝から雪が降っていますね。
今日からDevelopers Summit 2010が開催されるので、参加者に影響がなければいいですね。
私も登録してあるので、仕事で時間ができれば伺いたいと思っています。
発表者の方々是非頑張ってください。
河津桜まつり
昨日、日曜日に河津桜まつりに日帰りで行ってきました。
河津は一昨年に続き２回目となるのですが、昨日の時点では全体的に、まだツボミも多く、５分〜７分咲きといった所ではなかったでしょうか。次の土・日曜日辺りが満開になるのではないかと思いますのでご興味のある方は行ってみてください。いくつか写真を撮ってきました。
河津桜まつり
河津桜まつり
河津桜まつり
行きは沼津経由で行き、帰りは箱根経由で戻って来たのですが、いずれも山には結構雪が積もっていました（運転手だったので雪を写真におさめれなかったのですが）。特に箱根の頂上辺りは極寒で、車の温度計が−２℃（夕方５時頃）を指していました、山の上はまだまだ真冬なのに、同じ日に春の象徴の桜もみれて、ギャップを楽しむことができた一日でした。
バンビ
昨日は妻の実家で飼っているバンビも連れていったのですが、、今回はなかなか良い顔をしてくれませんでした。ちなみにこれ獲物（お菓子）を狙う目です。下はごちそうさまの顔。
バンビ
GlassFish SSLの設定 (サーバ証明書の設定)
※ GlassFish で証明書の管理や鍵の管理を行う場合、
管理コンソールからは行えません．コマンドを使用してください．
SSLの設定(サーバ認証の設定)
クライアントのWebブラウザからサーバに対してSSL通信を行う場合，通常アプリケーションサーバの前段に配置するロードバランサもしくはリバースプロキシなどのシステムでSSL設定を行い，前段のシステムとアプリケーションサーバ間はSSLによる通信を行わない場合が多いです．しかしミッションクリティカルな環境では，前段のシステムとアプリケーションサーバ間もセキュアな通信路を確保する必要があリます．そのような場合，アプリケーションサーバ上でもSSLのサーバ証明書を設定する必要があります．ここでは前段のシステムからSSLで負荷分散されることを想定しクラスタ環境に対してSSLの設定を行う方法について紹介します．単一サーバインスタンスに対する設定を行う場合も基本的には同様の手続きで可能ですので参考にしてください．
今回紹介するクラスタ環境におけるSSL証明書管理の利点は，クラスタ構成に対して一度だけ設定を行えばクラスタに所属する全てのインスタンスに対して共通のSSL設定が有効になりますので，管理するマシンの台数が多い場合非常に便利です。
GlassFishのSSL設定はサーバ証明書のニックネームを変更する以外の殆どの設定操作をコマンドを使用して行います．そこで以下の説明では全ての操作をコマンドを使用して管理する方法を紹介します．
また，下記の手順は開発者プロファイル，クラスタプロファイル(Sun GlassFish Enterprise Server/OSS版GlassFish)を使用した場合の方法を紹介します．開発者プロファイル，クラスタプロファイルを使用する場合，証明書の管理にJava SEに付属するkeytoolを使用して管理します．エンタープライズプロファイル(Sun GlassFish Enterprise Server with HADB)を使用する場合は，NSS (Network Security Service)のcertutilコマンドやライブラリを使用します．certutilコマンドを使用した証明書管理方法は別途「GlassFish Enteprise Server管理ガイド」をご参照ください．
既存の自己署名証明書の確認
keytoolの-listコマンドを使用してGlassFishのインストール時に，デフォルトでインストールされている証明書を確認できます．証明書のキーストアはドメインのconfigディレクトリ中に存在しています．keystore.jksにはサーバ証明書などを格納します．またcacerts.jksには認証局(CA)の証明書などを格納します．
| dashost > cd /export/home/appserv/domains/clusterDomain/config/ dashost > ls keystore.jks cacerts.jks cacerts.jks keystore.jks dashost > keytool -list -keystore ./keystore.jks -alias s1as -storepass changeit s1as, 2009/12/03, PrivateKeyEntry, 証明書のフィンガープリント (MD5): E7:3A:3C:2A:F1:AE:7D:E8:72:0D:E5:A7:AE:87:97:DA dashost > keytool -list -keystore cacerts.jks -alias s1as -storepass changeit s1as, 2009/12/03, trustedCertEntry, 証明書のフィンガープリント (MD5): E7:3A:3C:2A:F1:AE:7D:E8:72:0D:E5:A7:AE:87:97:DA |
鍵のペア(公開鍵および関連する非公開鍵)の生成
keytoolの-genkeypairコマンドを使用して鍵のペアを生成します．クラスタ環境では実際の接続先はクラスタに所属するノードエージェントのホスト名になるため，CNにワイルドカードでホスト名を指定(*.japan.sun.com)することをおすすめします．ワイルドカードを使用すると，実際の接続先がnodeagent1.japan.sun.comやnodeagent2.japan.sun.comであった場合も正当なサーバ証明書として利用できます．単一のサーバインスタンスに対するサーバ証明書を作成する際は，CNに対してサーバ名をFQDN(www.japan.sun.com)で指定してください．
| dashost > keytool -genkeypair -alias cluster -keystore keystore.jks -keyalg RSA -keysize 2048 -validity 365 -dname “CN=*.japan.sun.com, OU=Software Practice, O=Sun Microsystems, L=Setagaya, ST=Tokyo, C=JP” -storepass changeit -keypass changeit |
証明書署名要求(CSR)の生成
keytool の-certreqコマンドを使用して証明書署名要求(CSR)を作成します．クラスタ環境における実際の接続先はクラスタに所属するノードエージェント上のインスタンスになるため，ワイルドカードでホスト名を指定することをおすすめします．ワイルドカードを使用すると，実際の接続先がnodeagent1.japan.sun.comやnodeagent2.japan.sun.comであった場合も正当なサーバ証明書として利用できます．(単一のサーバインスタンスに対してサーバ証明書を作成する際は，*(アスタリスク)の代わりにサーバ名をFQDNで指定してください．)
| dashost > keytool -certreq -alias cluster -keystore ./keystore.jks -file cluster.japan.sun.com.csr -storepass changeit |
署名前のサーバ証明書の確認
下記のコマンドを実行しkeytoolで作成したCSRの内容を確認します．
| dashost > openssl req -text -in ./cluster.japan.sun.com.csr Certificate Request: Data: Version: 0 (0x0) Subject: C=JP, ST=Tokyo, L=Setagaya, O=Sun Microsystems, OU=Software Practice, CN=*.japan.sun.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) (省略) |
認証局(CA)でサーバ証明書を署名
GlassFish 上で生成した CSR を元に認証局で署名を行います．
| ca-server > openssl ca -in cluster.japan.sun.com.csr -keyfile ./demoCA/private/cakey.pem -cert ./demoCA/cacert.pem -out /tmp/signed-cluster.japan.sun.com.cert Using configuration from /usr/local/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: cd:ea:db:f4:c8:e3:93:8f (省略) Certificate is to be certified until Dec 3 11:23:45 2010 GMT (365 days) Sign the certificate? [y/n]: y 1 out of 1 certificate requests certified, commit? [y/n] y Write out database with 1 new entries Data Base Updated |
認証局(CA)でサーバ証明書をバイナリ(DER)形式に変換
keytool で証明書(鍵)データベースに保存するため，署名された証明書(signed-cluster.japan.sun.com.cert)をバイナリ(DER)形式(signed-cluster.japan.sun.com.der)に変換します．
| ca-server > openssl x509 -in /tmp/signed-cluster.japan.sun.com.cert -outform DER -out /tmp/signed-cluster.japan.sun.com.der |
認証局(CA)の証明書(cecert.pem)からX.509形式の証明書を準備
自己認証局によって署名されたサーバ証明書をGlassFishにインポートする前に，認証機関の証明書をGlassFishの証明書(鍵)データベースにインポートする必要があります．下記のように認証局のX.509形式のフォーマットを別ファイルにコピー＆ペーストして保存してください．
| dashost > vi cacert.x509 “cacert.x509” [新規ファイル] —–BEGIN CERTIFICATE—– MIIDmTCCAwKgAwIBAgIJAM3q2/TI45OEMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYD VQQGEwJKUDEOMAwGA1UECBMFVG9reW8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3Rl bXMxGjAYBgNVBAsTEVNvZnR3YXJlIFByYWN0aWNlMRowGAYDVQQDExFjYS1zZXJ2 ZXIuc3VuLmNvbTEeMBwGCSqGSIb3DQEJARYPY2FhZG1pbkBTdW4uQ09NMB4XDTA5 MTEwOTA0NDAwOVoXDTEyMTEwODA0NDAwOVowgZAxCzAJBgNVBAYTAkpQMQ4wDAYD VQQIEwVUb2t5bzEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczEaMBgGA1UECxMR U29mdHdhcmUgUHJhY3RpY2UxGjAYBgNVBAMTEWNhLXNlcnZlci5zdW4uY29tMR4w HAYJKoZIhvcNAQkBFg9jYWFkbWluQFN1bi5DT00wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALbumBZl+9qUSGdxADtmgW8JRlriRmwOgOoYyrifayZz7to2SB09 +gk7alqzEFz1vFA2jUZu4X8veWMP/PLFvmjwPVXtSbk3HeRWosinb0ge49sX1/Nl GOe90wGQzxci30O6V8FlHo1bWt9p/SSXZzLAtSn9Y5Au1GlpGHO4gL4hAgMBAAGj gfgwgfUwHQYDVR0OBBYEFB24TDDMoTWycjWgisz6+RecxNJKMIHFBgNVHSMEgb0w gbqAFB24TDDMoTWycjWgisz6+RecxNJKoYGWpIGTMIGQMQswCQYDVQQGEwJKUDEO MAwGA1UECBMFVG9reW8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbXMxGjAYBgNV BAsTEVNvZnR3YXJlIFByYWN0aWNlMRowGAYDVQQDExFjYS1zZXJ2ZXIuc3VuLmNv bTEeMBwGCSqGSIb3DQEJARYPY2FhZG1pbkBTdW4uQ09NggkAzerb9Mjjk4QwDAYD VR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQAyiypjUnJBMMyy615ZYM3oOUYZ 3UgwLOnos/rGGCov9CIcxiLH8PcXc3IXRYgRFDqINRhSqfDrjt4YP9cz4QmEbNqy 9wPxrje4HPYZU+AKErN7Wt058dKFSeA+Wp2JsDiwdoARy4Ow/j/tkhVoOm07E3fM TbEdS42dtkHlBgdSrw== —–END CERTIFICATE—– |
GlassFish 上で認証局の証明書をインポート
認証期間の署名書(cacert.x509)を，GlassFishが稼働するマシン上にコピーしそれぞれ証明書データベース，鍵データベースにインポートしてください．
| dashost > keytool -import -file /tmp/cacert.x509 -trustcacerts -alias private-ca -keystore keystore.jks -storepass changeit 所有者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP 発行者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP シリアル番号: cdeadbf4c8e39384 有効期間の開始日: Mon Nov 09 13:40:09 JST 2009 終了日: Thu Nov 08 13:40:09 JST 2012 証明書のフィンガープリント: MD5: 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48 SHA1: 00:3C:55:1E:34:60:FC:77:24:38:7E:64:39:C4:38:48:79:92:2F:31 署名アルゴリズム名: SHA1withRSA バージョン: 3 (省略) この証明書を信頼しますか? [no]: yes 証明書がキーストアに追加されました。 |
| dashost > keytool -import -file /tmp/cacert.x509 -trustcacerts -alias private-ca -keystore cacerts.jks -storepass changeit 所有者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP 発行者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP シリアル番号: cdeadbf4c8e39384 有効期間の開始日: Mon Nov 09 13:40:09 JST 2009 終了日: Thu Nov 08 13:40:09 JST 2012 証明書のフィンガープリント: MD5: 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48 SHA1: 00:3C:55:1E:34:60:FC:77:24:38:7E:64:39:C4:38:48:79:92:2F:31 署名アルゴリズム名: SHA1withRSA バージョン: 3 (省略) この証明書を信頼しますか? [no]: yes 証明書がキーストアに追加されました。 |
GlassFish上で認証局(CA)で署名されたサーバ証明書をインポート
認証局の証明書をインポートした後に，認証局で署名されたバイナリ(DER)形式のサーバ証明書を鍵データベースにインポートします。この時このサーバ証明書を識別するためのエイリアスとして cluster という名前を設定して実行します．
| dashost > keytool -import -alias cluster -file /tmp/signed-cluster.japan.sun.com.der -keystore keystore.jks -storepass changeit 証明書応答がキーストアにインストールされました。 |
署名済みサーバ証明書をインポートした後，鍵データベースの内容を確認してみましょう．
| dashost > keytool -list -keystore keystore.jks -storepass changeit キーストアのタイプ: JKS キーストアのプロバイダ: SUN キーストアには 3 エントリが含まれます。 cluster, 2009/12/03, PrivateKeyEntry, 証明書のフィンガープリント (MD5): 2A:50:2A:50:1E:B9:3F:42:DB:4C:AF:8D:48:38:AB:05 private-ca, 2009/12/03, trustedCertEntry, 証明書のフィンガープリント (MD5): 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48 s1as, 2009/12/03, PrivateKeyEntry, 証明書のフィンガープリント (MD5): B0:69:F8:C5:C0:09:44:D7:0C:9A:06:4B:33:53:E0:05 |
次に，インポートしたサーバ証明書をクラスタ環境で利用できるように，クラスタで使用するSSLのサーバ証明書ニックネームを全てs1asからcluster変更します．クラスタ設定で s1as を参照するSSLの設定一覧を表示し確認します．
| dashost > asadmin get “*” | grep cluster1 | grep s1as cluster1-config.admin-service.jmx-connector.system.ssl.cert-nickname = s1as cluster1-config.http-service.http-listener.http-listener-2.ssl.cert-nickname = s1as cluster1-config.iiop-service.iiop-listener.SSL.ssl.cert-nickname = s1as cluster1-config.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname = s1as cluster1.admin-service.jmx-connector.system.ssl.cert-nickname = s1as cluster1.http-service.http-listener.http-listener-2.ssl.cert-nickname = s1as cluster1.iiop-service.iiop-listener.SSL.ssl.cert-nickname = s1as cluster1.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname = s1as |
s1as の証明書ニックネームを参照している全ての設定をasadmin setコマンドを使用してclusterに変更します．
| dashost > asadmin set cluster1-config.admin-service.jmx-connector.system.ssl.cert-nickname=cluster dashost > asadmin set cluster1-config.http-service.http-listener.http-listener-2.ssl.cert-nickname=cluster dashost > asadmin set cluster1-config.iiop-service.iiop-listener.SSL.ssl.cert-nickname=cluster dashost > asadmin set cluster1-config.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname=cluster dashost > asadmin set cluster1.admin-service.jmx-connector.system.ssl.cert-nickname=cluster dashost > asadmin set cluster1.http-service.http-listener.http-listener-2.ssl.cert-nickname=cluster dashost > asadmin set cluster1.iiop-service.iiop-listener.SSL.ssl.cert-nickname=cluster dashost > asadmin set cluster1.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname=cluster |
上記で，GlassFish のサーバ証明書の設定はすべて完了です．設定内容を反映させるため，最後にクラスタを再起動します．
| dashost > asadmin stop-cluster cluster1 クラスタ化されたインスタンス instance1 の停止に成功しました。 クラスタ化されたインスタンス instance2 の停止に成功しました。 コマンド stop-cluster は正常に実行されました。 dashost > asadmin start-cluster cluster1 クラスタ化されたインスタンス instance1 の起動に成功しました。 クラスタ化されたインスタンス instance2 の起動に成功しました。 コマンド start-cluster は正常に実行されました。 |
ブラウザからアクセスして証明書の内容を表示すると，
ca-server.sun.comによって署名されたサーバ証明書を確認できます．
ブラウザでサーバ証明書の内容を確認
SSL 設定に関するデバッグ方法
最後に、SSLの設定に関するデバッグ方法を紹介します．SSLの設定で何らかの問題が発生した場合は，下記コマンドを実行して各インスタンスのログを確認してください．
| dashost > asadmin create-jvm-options –target cluster1 “-Djavax.net.debug=ssl” コマンド create-jvm-options は正常に実行されました。 dashost > asadmin stop-cluster cluster1 クラスタ化されたインスタンス instance1 の停止に成功しました。 クラスタ化されたインスタンス instance2 の停止に成功しました。 コマンド stop-cluster は正常に実行されました。 dashost > asadmin start-cluster cluster1 クラスタ化されたインスタンス instance1 の起動に成功しました。 クラスタ化されたインスタンス instance2 の起動に成功しました。 コマンド start-cluster は正常に実行されました。 |
証明書失効リスト(CRL)のチェック方法については下記のブログを参照してください．
http://weblogs.java.net/blog/kumarjayanti/archive/2007/11/ssl_and_crl_che.html
GlassFish サーバインスタンス
サーバインスタンス
サーバインスタンスはエンドユーザ向けにサービスを提供するJava EE 5の 仕様に完全準拠したJava EEのプロセスです．１つのドメ イン内には複数のサーバインスタンスを作成する事ができます．また物理的にハードウェアが異なる環境上でインスタンスを作成する事もできます．ドメイン内 で複数のサーバインスタンスを作成する場合，それぞれのサーバインスタンスを識別するために，異なる名前を設定する必要があります．
サーバインスタンスは下記の２種類のいずれかの方法で作成できます．
- クラスタに所属しないインスタンス
- クラスタに所属しないインスタンス
クラスタについては別途，詳細に説明しますが，複数のサーバインスタンスを作成する環境では，クラスタへの所属の有無に応じて，アプリケーションの配備やリソース設定等の管理方法が大幅に異なってきます．具体的に はクラスタに属する全てのインスタンスは，クラスタに対する設定情報が各インスタンスに完全に引き継がれるため，たった１度のクラスタに対する操作で全て のインスタンスに対して反影されます．このようにクラスタに所属するインスタンスは，同じアプリケーションを負荷分散や高化用性を実現するために複数台の マシンで実行したいような場合に有効です．一方，クラスタに所属しないインスタンスは，各インスタンス間で設定情報を独立に設定するため，リソース設定を 個別に管理したい場合，単一のアプリケーションを別のJava VMプ ロセスで稼働させたい場合，もしくは異なるアプリケーションをそれぞれ別のJava VMの プロセスで稼働させたいような場合に有効です．
サーバインスタンスのアーキテクチャを「図5：サーバインスタンスのアーキテク チャ」に示します．のようにプロセス内にEJBコンテナやWebコンテナ等を含み，各種クライアントからの要求を受け 付けます．
図 5:サーバインスタンスのアー キテクチャ
サーバインスタンス単位，もしくはクラスタ構成単位に「図6： インスタンス毎の設定項目」に示す項目の設定が可能です．
図 6:インスタンス毎の設定項目
Creator Pack For NetBeans
さて、今日は久々にCreatorネタを少しアップデートします。
以前から数多くの御客様から御要望をいただいていたのですが、
CreatorとNetBeansの統合についてですが、少しだけ情報がでてきました。
Creator2とNetBeansの統合計画(Shortfinというプロジェクト名で)が
本格的に進みだしたようです。
まだ、色々と仕様をつめている段階のようで、NetBeansの既存の画面項目と
Creatorの画面項目をどのように統合すべきか？等さまざまな議論がされている状況で
サンプルの画面もまだまだ御見せできない段階なのですが、
実はこのネタ今年のJava One 2006の前日のNetBeans Dayで紹介されたようです。（すいませんちょっと古いネタで。）
Winston Prakash’s Weblog
http://blog.sun.com/roller/page/winston?entry=creator_pack_for_netbeans
これにより、NetBeansは統合開発環境としてモバイルからリッチクライアント
Webアプリケーションからエンタープライズ分野まで全てを網羅できるようになりそうです。
是非、このCreator Pack For NetBeansを楽しみにしておいてください。
寺田 佳央 - Yoshio Terada 