2015年11月23日

[Java, WLS, Database, FMW] WLS Replay Statistics

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/wls_replay_statistics

12.1.0.2 Oracle JDBC thinドライバから、リプレイドライバはリプレイに関連する統計情報を持っています。これは何個の接続を再生するか理解する上で役立ちます。完全にアプリケーションに対して透過的なので、接続リプレイはチェックしない限りわからないことでしょう。

統計情報は接続ごと、もしくはデータソース毎に利用可能ですが、WebLogic Serverのデータソースの接続はドライバレベルのデータソースオブジェクトを共有しないので、後者(データソース毎の統計情報)はWebLogic Serverでは有用ではありません。WebLogic Server 12.2.1ではデータソースレベルでの統計情報を取得するための別の機構を提供します。

以下のサンプルコードは、oracle.jdbc.replay.ReplayableConnectionインターフェースを使う個々の接続に対する利用可能な統計情報を出力する方法を示しています。このインターフェースはoracle.jdbc.replay.ReplayStatisticsオブジェクトを取得するメソッドを使えるようにするものです。統計情報値の詳細は、以下のドキュメントをご覧下さい。
Oracle®Database JDBC Java API Reference 12c Release 1 (12.1.0.2)
oracle.jdbc.replay
Interface ReplayStatistics
https://docs.oracle.com/database/121/JAJDB/oracle/jdbc/replay/ReplayStatistics.html
if (conn instanceof ReplayableConnection) {
  ReplayableConnection rc = ((ReplayableConnection)conn);
  ReplayStatistics rs = rc.getReplayStatistics(
     ReplayableConnection.StatisticsReportType.FOR_CURRENT_CONNECTION);
  System.out.println("Individual Statistics");
  System.out.println("TotalCalls="+rs.getTotalCalls());
  System.out.println("TotalCompletedRequests="+rs.getTotalCompletedRequests());
  System.out.println("FailedReplayCount="+rs.getFailedReplayCount());
  System.out.println("TotalRequests="+rs.getTotalRequests());
  System.out.println("TotalCallsTriggeringReplay="+rs.getTotalCallsTriggeringReplay());
  System.out.println("TotalReplayAttempts="+rs.getTotalReplayAttempts());
  System.out.println("TotalProtectedCalls="+rs.getTotalProtectedCalls());
  System.out.println("SuccessfulReplayCount="+rs.getSuccessfulReplayCount());
  System.out.println("TotalCallsAffectedByOutages="+rs.getTotalCallsAffectedByOutages()); 
  System.out.println("TotalCallsAffectedByOutagesDuringReplay="+  
       rs.getTotalCallsAffectedByOutagesDuringReplay());  
  System.out.println("ReplayDisablingCount="+rs.getReplayDisablingCount());
}
getReplayStatistics()メソッドに加えて、clearReplayStatistics()メソッドもあります。

WebLogic Serverデータソースに関連付けられているすべての接続の統合ビューを提供するために、関連付けられているランタイムMBeanの新しいオペレーションを使って情報を取り出すことができます。このとき、WebLogic Server MBeanサーバを検索し、JDBCサービスを取得してから、JDBCデータソースのランタイムMBeanのリストにあるデータソース名を検索し、JDBCReplayStatisticsRuntimeMBeanを取得する必要があります。なお、データソースがリプレイドライバを使っていない場合、ドライバーが12.1.0.2より前の場合、または汎用データソース、AGL(Active GridLink)データソースではない場合、この値はnullになります。リプレイ情報を使うためには、データソースの全ての接続を集約するため、MBean値を設定するrefreshStatics()をまず呼び出す必要があります。その後、以下のサンプルコードのように、MBeanのオペレーションを呼び出して統計値を取得することができます。データソースの全接続の統計情報をクリアするためのclearStatistics()もあります。以下のサンプルコードは、データソースから集約した統計情報を表示するものです。
public void printReplayStats(String dsName) throws Exception {
  MBeanServer server = getMBeanServer();
  ObjectName[] dsRTs = getJdbcDataSourceRuntimeMBeans(server);
  for (ObjectName dsRT : dsRTs) {
    String name = (String)server.getAttribute(dsRT, "Name");
    if (name.equals(dsName)) {
      ObjectName mb =(ObjectName)server.getAttribute(dsRT,  
        "JDBCReplayStatisticsRuntimeMBean");
      server.invoke(mb,"refreshStatistics", null, null);
      MBeanAttributeInfo[] attributes = server.getMBeanInfo(mb).getAttributes();
      System.out.println("Roll-up");
      for (int i = 0; i <attributes.length; i++) {
        if(attributes[i].getType().equals("java.lang.Long")) {
          System.out.println(attributes[i].getName()+"="+
            (Long)server.getAttribute(mb, attributes[i].getName()));
        }
      }
    }
  }
}
MBeanServer getMBeanServer() throws Exception {
  InitialContext ctx = new InitialContext();
  MBeanServer server = (MBeanServer)ctx.lookup("java:comp/env/jmx/runtime");
  return server; 
 }
ObjectName[] getJdbcDataSourceRuntimeMBeans(MBeanServer server) throws Exception {
  ObjectName service = new ObjectName( "com.bea:Name=RuntimeService,Type=weblogic.management.mbeanservers.runtime.RuntimeServiceMBean");
  ObjectName serverRT = (ObjectName)server.getAttribute(service,  "ServerRuntime");
  ObjectName jdbcRT = (ObjectName)server.getAttribute(serverRT,  "JDBCServiceRuntime");
  ObjectName[] dsRTs = (ObjectName[])server.getAttribute(jdbcRT,
    "JDBCDataSourceRuntimeMBeans");
  return dsRTs;
}
では、接続を取得し、ワークを実行し、セッションを切り、リプレイし、その後次の接続を取得して同じことをするアプリケーションを実行します。各接続は一度リプレイすることに成功します。つまり、個々の統計情報が1回のリプレイを表示し、集約された統計情報が2個のリプレイを表示します。以下のような出力となって現れます。
Individual Statistics
TotalCalls=35
TotalCompletedRequests=0
FailedReplayCount=0
TotalRequests=1
TotalCallsTriggeringReplay=1
TotalReplayAttempts=1
TotalProtectedCalls=19
SuccessfulReplayCount=1
TotalCallsAffectedByOutages=1
TotalCallsAffectedByOutagesDuringReplay=0
ReplayDisablingCount=0
 
Roll-up
TotalCalls=83
TotalCompletedRequests=2
FailedReplayCount=0
TotalRequests=4
TotalCallsTriggeringReplay=2
TotalReplayAttempts=2
TotalProtectedCalls=45
SuccessfulReplayCount=2
TotalCallsAffectedByOutages=2
TotalCallsAffectedByOutagesDuringReplay=0
ReplayDisablingCount=0
個数をよく見ると、接続を閉じる(TotalCompletedRequests=0)前に個々のカウントがなされ、roll-upは両方の接続を閉じた後になされていることがわかります。

WLSTを使ってデータソースの統計値を取得することもできます。統計値はWebLogic Server 12.2.1のWebLogic Server管理コンソールやFusion Middleware Controlでは見ることはできません。

2015年11月22日

[Java, Database] The top 10 JDBC documents that are linked as solutions from May 2015 to Nov 2015

原文はこちら。
https://blogs.oracle.com/proactivejavadevelopment/entry/new_entry_for_jdbc

2015年5月から2015年11月までの間で、JDBCの問題に対する解決策につながったJDBCのドキュメントのトップ10を、下表にまとめました。
401934.1 Starting With Oracle JDBC Drivers
このFAQではOracle JDBCドライバを使うにあたって実用的な情報を提供します。どのOracle JDBCドライバをJavaアプリケーションで利用できるかを選択できるように、Oracle JDBCドライバの説明を提供しています。
1361107.1 Troubleshooting ORA-3137 [12333] Errors Encountered When Using Oracle JDBC Driver 
RDBMSにOracle JDBCドライバで接続した際にお客様が経験された数多くのORA-3137[12333]やORA-3137[1010]の問題をOracle Customer Supportは見てきました。このドキュメントでは、解決したことが証明されているトラブルシューティングのアプローチを列挙します。
467804.1 How To Determine The Exact JDBC Driver Version (9.x - 11.x) For Standalone Programs
サポート・アナリストにとって特に有用な、JDBC/JDK環境の診断情報を取得します。これには、データベースのバージョン、JDBCドライバのバージョン、JDKのバージョン、PATH、ブートストラップ、JRE拡張ディレクトリのjarのリスト、CLASSPATHとJDBC URLを含みます(スタンドアロン・プログラム向けです)。
1050942.1 How to Trace the Network Packets Exchanged Between JDBC and the RDBMS in Release 11.2 
Oracle JDBCドライバ 11.2とOracle Database間で送受信しているものをトレースする方法を説明しています。
755605.1 Error "ORA-28040: No matching authentication protocol" When Using SQLNET.ALLOWED_LOGON_VERSION
10.2 thin JDBCドライバは自身を8.1.5クライアントとして識別するため、接続がORA-28040(一致する認証プロトコルがありません)で失敗します。
467808.1 Standard JDBC diagnostics for Application Servers
サポート・アナリストにとって特に有用な、Java EEコンテナ内で使われているJDBC/JDK環境の診断情報を取得します。これには、データベースのバージョン、JDBCドライバのバージョン、JDKのバージョン、PATH、ブートストラップ、JRE拡張ディレクトリのjarのリスト、CLASSPATHとJDBC URL、デバッグフラグ情報を含みます(Application Server固有)。
2000339.1 ORA-28040 and SQLNET.ALLOWED_LOGON_VERSION_CLIENT for JDBC Thin Clients
thinドライバ利用時に発生するORA-28040(一致する認証プロトコルがありません)の解決方法を説明しています。
1555793.1 JDBC Connections Using SCAN Fail With ORA-12516/ORA-12520
SCANを使ったJDBC接続時に以下のエラーで失敗する場合の解決方法
  • ORA-12520: TNS:リスナーは、リクエストしたサーバータイプに使用可能なハンドラを検出できませんでした
  • ORA-12516: TNS: リスナーは、一致するプロトコル・スタックが使用可能なハンドラを検出できませんでした。
793415.1 How to Perform the Equivalent of SQL*Net Client Tracing with Oracle JDBC Thin Driver
Oracle JDBC thinドライバはJavaベースのSQLNETプロトコル(JavaNet層)の実装を使っています。
334471.1 Understanding Transparent Application Failover (TAF) and Fast Connection Failover (FCF)
このNoteは透過的アプリケーションフェールオーバ(Transparent Application Failover / TAF)と高速接続フェールオーバ(Fast Connection Failover / FCF)という、2個のRACのコンセプトを説明することを目的としています。

2015年11月20日

[WLS, FMW] Zero Downtime Patching Released!

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/wls_mt_diagnostics_overview

WebLogic Serverへのパッチ適用やアップデートがずっと簡単になりました。Zero Downtime Patchingのリリースは、WebLogic Serverのメンテナンスの簡素化と、継続的な可用性を提供する機能に対するOracleのコミットメントにおいて、大きな前進を示すものです。

Zero Downtime Patchingを使うと、配布されたパッチを複数のクラスタやドメイン全体に対し、1コマンドでロールアウトできます。このとき、エンドユーザー向けのサービス停止やセッションデータの損失を引き起こすことはありません。かつては退屈で時間のかかるタスクだったものが、一貫性のある、効率的で柔軟な自動化されたプロセスに置き換わります。

このプロセスを自動化することにより、人手による入力(つまりエラーを引き起こす要因)を劇的に削減することができ、変更前に、入力内容を検証することができます。これはプロセスの一貫性および信頼性に大きな影響があり、またプロセスの効率を劇的に向上するものです。

エラーが発生したときにステップを再試行できたり、問題解決のため一時停止、中断した箇所から再開できたり、もしくは必要であれば、環境全体を元の状態に戻すことができたりする、という点で、プロセスには弾力性があります。

管理者は、パッチを適用したOracleHomeアーカイブを既存の慣れたツールで作成・確認検証し、アーカイブをアップグレードしたい各ノードに配置してから、以下のシンプルなコマンドで以後の処理を実行します。
rolloutOracleHome("Cluster1, Cluster2", "/pathTo/patchedOracleHome.jar", "/pathTo/backupOfUnpatchedOracleHome")
このプロセスを機能させる方法は、ロードバランサであるOracle Traffic Director (OTD) と組み合わせた既存のクラスタリング技術を活用して、アップデート時に個々のノードをオフラインにすることができます。ロードバランサと通信し、アクティブなノードにリクエストをリダイレクトすることを指示します。また、アクティブなセッションを保存するためのいくつかの高度なtechiquesを作成したので、エンドユーザーにもパッチ適用が行われていることはわからないでしょう。

サーバで利用しているJavaのアップデートや実行中のアプリケーションへのアップデートなどにも、同じプロセスを活用することができます。エンドユーザ向けのサービス停止はまったくありません。

ここで説明することになるであろうZero Downtime (ZDT) Patchingには、たくさんのおもしろい特徴がありますので、乞うご期待!

Zero Downtime Patchingに関する詳細は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
http://docs.oracle.com/middleware/1221/wls/WLZDT/index.html

[WLS, FMW] Oracle WebLogic Server 12.2.1 Continuous Availability

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/oracle_weblogic_server_12_2

Oracle WebLogic Server 12.2.1の新機能であるContinuous Availabilityは、マルチデータセンターアーキテクチャを構成するためのEnd to Endのソリューションです。Continuous Availabilityを使うと、マルチデータセンター環境で実行しているアプリケーションは引き続きActive-Active環境で実行することができます。一方のサイトに障害が発生した場合、他方のサイトが停止したサイトのワークを回復します。アップグレードの間、アプリケーションは停止せずに引き続き実行できます。紐付けているのは自動化されたデータサイト・フェールオーバーで、フェールオーバやスイッチオーバイベント中の人的エラーとリスクを低減することを目的としています。

Reduce Application Downtime

WebLogic Zero Down Time Patching (ZDT)

停止やセッションの消失を避けつつ、パッチのロールアウトやアップデートを自動的にオーケストレーションします。ロールアウトプロセスの自動化により、リスク、コスト、セッションの停止時間を削減します。ZDTは失敗時に自動的に再実行し、試行に失敗した場合にはロールバックします。この機能の詳細を知りたい方は、以下のエントリをご覧ください。
Zero Downtime Patching Released!
https://blogs.oracle.com/WebLogicServer/entry/zero_downtime_patching_released
http://orablogs-jp.blogspot.jp/2015/11/zero-downtime-patching-released.html

WebLogic Multitenant Live Partition Migration

Multitenant環境において、ライブパーティションマイグレーションは、アプリケーションユーザへ影響を与えずに、実行中のパーティションやリソースグループを一方のクラスタから別のクラスタへ移行できる機能です。 アップグレード、負荷分散、もしくは切迫したパーティションの障害時に、アプリケーションに影響を与えずに移行することができます。

Coherence Persistence

永続ストレージにキャッシュデータとメタデータを永続化します。一つ以上のCoherenceサーバもしくはクラスタ全体に障害が発生した場合、永続データとメタデータを回復することができます。


Replicate State for Multi-Datacenter Deployments

WebLogic Cross Domain XA Recovery

あるサイトもしくのWebLogic Serverドメインがダウンした、もしくはサイト全体が落ちた場合、生存しているサイトのドメインのトランザクションを自動的に回復する機能です。この機能を使うと、Active-Active Maximum Availability Architecture (MAA) でトランザクションリカバリの自動化が可能です。

Coherence Federated Caching

Coherenceのアップデートを配布します。衝突を解決しながら、分散した地理的サイト間でCoherenceの更新を配布します。レプリケーション・モードは、データを連続的に複製し、アプリケーションによるローカルキャッシュデータへのアクセスを提供するActive-Active、パッシブなサイトがアクティブなサイトのバックアップとして機能するActive-Passive、Hubがキャッシュデータを分散したSpokeに対して複製するHub Spokeです。

Operational Support for Site Failover

Oracle Traffic Director (OTD):

高速で信頼性の高い、拡張性の富んだソフトウェアロードバランサで、ネットワーク上のアプリケーションやWebサーバへトラフィックをルーティングします。Oracle Traffic Directorはサーバの状態を認識しており、サーバをクラスタに追加すると、OTDは追加されたサーバへのトラフィックルーティングを開始します。OTD自身はActive-Active、Active-Passiveのいずれのモードでも利用可能です。

Oracle Site Guard

End-to-Endのディザスタ・リカバリ自動化を提供します。Oracle Site Guardはフェールオーバやスイッチオーバを自動化します。サイトコンポーネントを事前に定義した順序で停止させ、スクリプトを走らせ、フェールオーバ後のチェックを実行します。Oracle Site guardはフェールオーバやスイッチオーバ時の停止時間と人的エラーを最小限にします。

Continuous Availabilityでは、アプリケーションのニーズに見合う、様々なトポロジーをサポートする柔軟性を提供しています。
  • Active-Activeアプリケーション層とActive-Passiveデータベース層の組合せ
  • Active-Passiveアプリケーション層とActive-Passiveデータベース層の組合せ
  • Active-Active StretchクラスタとActive-Passiveデータベース層の組合せ
Continuous Availabilityは最大の可用性と生産性、データの整合性とリカバリ、マルチデータセンター環境におけるデータのローカルアクセス、データのアップデートへのリアルタイムアクセス、サイトのフェイルオーバーやスイッチオーバーの自動化をアプリケーションにもたらし、フェイルオーバー/スイッチオーバー時の人的エラーやリスクを削減します。Continuous Availability機能でアプリケーションが停止しないよう、保護しましょう。Continuous Availabilityについて詳細を知りたい方は、以下のドキュメント、もしくはContinuous Availabilityを説明する動画をご覧ください。
Oracle® Fusion Middleware What's New in Oracle WebLogic Server 12.2.1 12c (12.2.1)
Continuous Availability
http://docs.oracle.com/middleware/1221/wls/NOTES/whatsnew.htm#NOTES610

[Java] Modularity in Java 9

原文はこちら。
https://blogs.oracle.com/java/entry/modularity_in_java_9

Alan BatemanとMark Reinholdによる4プレゼンテーションでJava 9について学びましょう。「Prepare for JDK 9」では、Alanが describes JDK 9での変更、既存コードや将来の開発への影響を説明しています。

「Introduction to Modular Development」では、Alanがモジュールの構造を説明し、基本モジュールをコンパイルしています。

「Advanced Modular Development」では、MarkがJDK自身を例として、モジュラー開発の一連の原則を説明しています。

「Project Jigsaw: Under the Hood」では、MarkがJava Platform Module Systemにおける可読性、可観測性、可視性、アクセスのしやすさの違いを説明しています。また、無名モジュール、プラットフォーム組み込みクラスローダ、異なる2バージョンのモジュールを動じにロード出来る方法を説明しています。

2015年11月19日

[WLS, Java, FMW] Weblogic Server 12.2.1 Multi-Tenancy Diagnostics Overview

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/wls_mt_diagnostics_overview

Introduction

WebLogic Server 12.2.1ではMultitenancyをサポートしており、これにより複数のテナントが一つのWebLogicドメインを共有することができます。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
About WebLogic Server MT
http://docs.oracle.com/middleware/1221/wls/WLSMT/concepts.htm#WLSMT718
テナントは、別々のWebLogicドメインの設定やランタイムインフラストラクチャのスライスを提供するドメインパーティションにアクセスします。
このエントリでは、各パーティションにデプロイされたアプリケーションやリソースに対しテナントが利用可能な診断・監視機能の概要を紹介します。

これらの機能はWebLogic Server Diagnostic Framework(WebLogic Server診断フレームワーク、WLDF)コンポーネントが提供します。
以下のトピックについて各セクションで説明します。

Log and Diagnostic Data

様々なソースからのログと診断データはパーティション管理者が利用できます。これらのログや診断データは以下のように大別できます。
  1. 共有データ - ログと診断データはパーティション管理者が直接生の永続化された形で利用することはできず、WLDFアクセッサコンポーネントを使ってのみ利用できる。
    Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
    Accessing Diagnostic Data With the Data Accessor
    http://docs.oracle.com/middleware/1221/wls/WLDFC/access_diag_data.htm#WLDFC272
  2. パーティションスコープのデータ - これらのログは、パーティションファイルシステムのディレクトリ配下でRaw形式でパーティション管理者が利用可能
WLDFデータアクセッサコンポーネントは、共有ログとパーティションスコープのログおよび、WebLogic Serverインスタンスでパーティションに対して利用可能とされている診断データにアクセスすることができますのでご注意ください。

以下の共有ログと診断データへは、パーティション管理者がアクセスできます。
ログの種類 内容
Server Server.logファイルに記録された、パーティションに関連する、サーバやアプリケーションコンポーネントからのログイベント
Domain パーティションに関連するWebLogicドメインのすべてのサーバインスタンスから収集されたログイベント。単一のログファイル。
DataSource パーティションに関連するDataSourceログイベント
HarvestedData Archive WLDF Harvesterがパーティションに関連するMBeanから収集したメトリックデータ
Instrumentation Events Archive パーティションにデプロイされたアプリケーションが生成するWLDFインストルメンテ-ションイベント

以下のパーティションスコープのログや診断データあはパーティション管理者からアクセスできます。
ログの種類 内容
HTPP access.log パーティションの仮想ターゲットのWebサーバからのHTTPアクセスログ
JMSServer パーティションを対象にしたリソースグループやリソースグループテンプレート内で定義されたJMSサーバリソースの、JMSサーバメッセージライフサイクルイベント
SAF Agent パーティションを対象にしたリソースグループやリソースグループテンプレート内で定義されたSAFエージェントリソースの、SAFエージェントメッセージライフサイクルイベント
Connector パーティション内のリソースグループやリソースグループテンプレートにデプロイされたJava EEリソースアダプタモジュールが生成したログデータ
Servlet Context パーティション内のリソースグループやリソースグループテンプレートにデプロイされたJava EE Webアプリケーションモジュールが生成する、サーブレットコンテキストログデータ

WLDF Accessor

WLDFアクセッサは診断データをJMX経由で取得するためのRuntimeBeanインターフェースを提供します。データのサブセットのみ取得するためのクエリ機能も提供しています。
この機能の詳細情報を知りたい方は、WLDFデータアクセッサのドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Accessing Diagnostic Data With the Data Accessor
http://docs.oracle.com/middleware/1221/wls/WLDFC/access_diag_data.htm#WLDFC272
WLDFPartitionRuntimeMBeanはPartitionRuntimeMBeanの子であり、WLDFランタイムMBeanのルートです。このMBeanは、パーティションを対象にしたWLDFアクセッサ機能のためのエントリポイントである、WLDFPartitionAccessRuntimeMBeanインターフェースのgetterを提供します。パーティションで利用可能な、各ログインスタンスに対するWLDFDataAccessRuntimeMBeanのインスタンスがあります。
WebLogic Server MBean Reference
WLDFPartitionRuntimeMBean
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/WLDFPartitionRuntimeMBean.html
PartitionRuntimeMBean
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionRuntimeMBean.html
WLDFPartitionAccessRuntimeMBean
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/WLDFPartitionAccessRuntimeMBean.html
WLDFDataAccessRuntimeMBean
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/WLDFDataAccessRuntimeMBean.html
事前定義された命名方式に従い、論理名によって異なるログが参照されます。
下表は異なるパーティション対象のログに対する論理名のパターンをまとめたものです。

Shared Logs

ログの種類 論理名
Server Log ServerLog
Domain Log DomainLog
JDBC Log DataSourceLog
Harvested Metrics HarvestedDataArchive
Instrumentation Events EventsDataArchive

Partition Scoped Logs

ログの種類 論理名
HTTP Access Log HTTPAccessLog/<Webサーバ名>
JMS Server Log JMSMessageLog/<JMSサーバ名>
SAF Agent Log JMSSAFMessageLog/<SAFエージェント名>
Servlet Context Log WebAppLog/<Webサーバ名>/context-path
Connector Log ConnectorLog/connection-Factory-jndiName$<パーティション名>

Logging Configuration

WebLogic Server Multitenancyはパーティション内で実行するアプリケーションコンポーネントが利用するjava.util.logging.Loggers内のレベルの構成をサポートしています。これにより、java.util.loggingを使うJava EEアプリケーションは、システムレベルのjava.util.loggingの設定機構にアクセスできなくても、それぞれのログレベルを設定することができるようになります。パーティション間で使われる、共通ライブラリが利用する共有ロガーインスタンスの場合、特定のパーティションに変わって設定しているのであれば、そのレベル構成もまたLoggerインスタンスに適用されます。
この機能はWebLogic Serverシステム管理者が、
-Djava.util.logging.manager=weblogic.logging.WLLogManager
というコマンドライン・システムプロパティを付けて起動した場合に有効になります。

WebLogic Serverを上述のようにカスタムログマネージャを使って起動すると、パーティション管理者は以下のようにロガーを構成できます。
WebLogic Server Multitenanctのドキュメント中にある、WLSTサンプルスクリプトをチェックしてください。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Configuring Partition Scope Debugging
http://docs.oracle.com/middleware/1221/wls/WLSMT/monitoring.htm#WLSMT1337
PartitionLogMBean.PlatformLoggerLevels属性で指定したレベルの設定は所有するパーティションに対してのみ有効です。同名のロガーインスタンスを別のパーティションで利用することができ、各ロガーの実行時の有効レベルは、それぞれのパーティションでのPartitionLogMBean.PlatformLoggerLevelsの設定によって定義されます。

Server Debug

あるトラブルシューティングのシナリオでは、パーティション固有のWebLogic Serverのサブシステムからのデバッグ出力を有効化する必要がある場合があります。サーバデバッグ出力はパーティションに代わって内部サーバコードのデバッグをする際に役に立ちますが、WebLogic Serverシステム管理者やOracle Supportと協同して注意しながら実施する必要があります。WebLogic Serverシステム管理者はまず ServerDebugMBean.PartitionDebugLoggingEnabled 属性を有効化する必要があります。その上で、特定のデバッグフラグを有効化するよう指示があります。これらのフラグはBoolean型の属性で、ServerDebugMBean構成インターフェースで定義されています。パーティションに対して有効化すべき特定のデバッグフラグをPartitionLogMBean.EnabledServerDebugAttributes属性を使って構成します。
WebLogic Server MBean Reference
PartitionLogMBean.EnabledServerDebugAttributes
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionLogMBean.html#EnabledServerDebugAttributes
パーティションに対して有効化するための特定のデバッグ出力の名前の配列(String型)を含んでいます。デバッグ出力をサーバログに記録します。この出力はWLDFアクセッサを使って取り出すことができ、Oracle Supportにより詳細の分析をするために提供することができます。サーバデバッグを有効化するとパフォーマンスのオーバーヘッドが発生するため、トラブルシューティングが終われば、デバッグフラグを無効化する必要があることにご注意ください。

パーティション固有のサーバデバッグを有効化する方法については、WebLogic Server MultitenancyドキュメントにあるWLSTサンプルスクリプトを参照してください。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Configuring Partition Scope Debugging
http://docs.oracle.com/middleware/1221/wls/WLSMT/monitoring.htm#WLSMT1337 

Diagnostic System Module for Partitions

Diagnostic System Module(DSM、診断システムモジュール)は、ハーベスタ、ポリシー、パーティションにデプロイされたリソースグループやリソースグループテンプレートで定義可能なActionコンポーネントを提供します。

Harvester

WLDFハーベスタはMBeanメトリック値を定期的にポーリングし、後の診断や分析用に収集したデータをアーカイブする機能を提供します。PartitionRuntimeMBeanとその子MBeanだけでなく、パーティションにデプロイされたアプリケーションが作成したMBeanも含め、パーティションから見えるすべてのWebLogic ServerランタイムMBeanを収集することができます。
WebLogic Server MBean Reference
PartitionRuntimeMBean
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionRuntimeMBean.html 
ハーベスタ構成では、サンプリング間隔、MBeanの主対、インスタンスの仕様、収集し永続化する必要のあるそれぞれのMBean属性を定義します。アーカイブされた収集済みメトリックデータは、前述の通りWLDFアクセッサコンポーネントから利用可能であることにご注意ください。
以下のXMLは、診断システムリソースXMLディスクリプタに永続化されたハーベスタの構成例です。
<harvester>
 <enabled>true</enabled>
 <sample-period>2000</sample-period>
 <harvested-type>
   <name>weblogic.management.runtime.ServletRuntimeMBean</name>
   <harvested-attribute>ExecutionTimeAverage</harvested-attribute>
   <namespace>ServerRuntime</namespace>
 </harvested-type>
 <harvested-type>
  <name>sandbox.mbean.SandboxCustomMBeanImpl</name>
  <namespace>ServerRuntime</namespace>
 </harvested-type>
</harvester>

WLDFハーベスタに関する詳細情報は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Configuring the Harvester for Metric Collection
http://docs.oracle.com/middleware/1221/wls/WLDFC/config_harvester.htm#WLDFC172

Policies and Actions

ポリシーとは、監視対象の条件をJavaの式言語(EL)で定義したルールです。WLDFでは、ルール条件を満足した場合に動き出すポリシーに添付することができるアクションを豊富に提供しています。

以下のタイプのルールベースのポリシーを定義することができます。
  • ハーベスタ:WebLogicランタイムMBeanのメトリックもしくはアプリケーションが有するカスタムMBeanのメトリックに基づく
  • ログイベント:サーバログやドメインログのログメッセージに基づく
  • インストゥルメンテ-ションイベント:WLDFインストゥルメンテ-ションを使うJava EEアプリケーションの測定コードから生成されたイベント
以下のスニペットはEL言語(EL式)を使ったポリシー構成の例です。
<watch>
  <name>Session-Count-Watch</name>
  <enabled>true</enabled>
  <rule-type>Harvester</rule-type>
    <rule-expression>wls.partition.query("com.bea:Type=WebAppComponentRuntime,*", "OpenSessionsCurrentCount").stream().anyMatch(x -> x >= 1)
  </rule-expression>
  <schedule>
    <minute>*</minute>
    <second>*/2</second>
  </schedule>
  <notification>jmx-notif1</notification>
</watch>
<watch>
  <name>Partition-Error-Log-Watch</name>
  <rule-type>Log</rule-type>
  <rule-expression>log.severityString == 'Error'</rule-expression>
  <notification>jmx-notif1,r1,r2</notification>
</watch>
<watch>
 <name>Inst-Trace-Event-Watch</name>
  <rule-type>EventData</rule-type>
  <rule-expression>instrumentationEvent.eventType == 'TraceAction'</rule-expression>
  <notification>jmx-notif1</notification>
</watch>
以下の種類のアクションをパーティションでサポートしています。
  • JMS
  • SMTP
  • JMX
  • REST
  • Diagnostic Image
ポリシーやアクションの構成について詳細は以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Configuring Policies and Actions
http://docs.oracle.com/middleware/1221/wls/WLDFC/config_watch_notif.htm#WLDFC188

Instrumentation for Partition Applications

WLDFは、パーティション・スコープにデプロイされたJava EEアプリケーションのためのバイトコード・インストゥルメンテ-ション・メカニズムを提供しています。アプリケーション用インストゥルメンテ-ションの構成は、META-INF/weblogic-diagnositcs.xml ディスクリプタファイルで指定します。

WebLogic Serverシステム管理者がサーバレベルのインストゥルメンテ-ションを有効化している場合にのみ、この機能は利用可能です。また、パーティションにわたってクラスローダを共有するアプリケーションに対しては利用できません。

以下はWLDFインストゥルメンテ-ションディスクリプタファイルの例です。
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
  <instrumentation><enabled>true</enabled>
  <wldf-instrumentation-monitor>
    <name>Servlet_Before_Service</name>
    <enabled>true</enabled>
  <action>TraceAction</action>
  </wldf-instrumentation-monitor>
  <wldf-instrumentation-monitor>
    <name>MyCustomMonitor</name>
    <enabled>true</enabled>
    <action>TraceAction</action>
    <location-type>before</location-type>
    <pointcut>execution( * example.util.MyUtil * (...))</pointcut>
  </wldf-instrumentation-monitor>
</instrumentation>
For further details refer to the WLDF Instrumentation documentation.

Diagnostic Image

診断イメージは単一のZipファイル中に様々なWebLogic Serverのサブシステムの状態をキャプチャするコアダンプに似ています。WLDFはパーティション固有の診断イメージのキャプチャをサポートしています。
診断イメージは以下の方法で取得できます。
パーティションのファイルシステムのlogs/diagnostic_imagesディレクトリにイメージを出力します。
パーティションイメージには以下のような様々なソースからの診断データが含まれています。
  • Connector
  • Instrumentation
  • JDBC
  • JNDI
  • JVM
  • Logging
  • RCM
  • Work Manager
  • JTA
詳細情報はWLDFのドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Configuring and Capturing Diagnostic Images
http://docs.oracle.com/middleware/1221/wls/WLDFC/config_diag_images.htm#WLDFC150

RCM Runtime Metrics

WebLogic server 12.2.1ではリソース消費管理(Resource Consumption Management, RCM)機能が導入されました。この機能はOracle JDK 8u40以後でのみ利用可能です。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Configuring Resource Consumption Management
http://docs.oracle.com/middleware/1221/wls/WLSMT/config_rcm.htm#WLSMT630
RCMを有効にするには、以下のコマンドラインスイッチをサーバー起動時のスクリプトに追加する必要があります。
-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC
RCMは起動スクリプトではデフォルトで有効化されていないことにご注意ください。
PartitionRuntimeMBeanの子であるPartitionResourceMetricsRuntimeMBeanは監視目的で役立つメトリックを提供します。
WebLogic Server MBean Reference
PartitionResourceMetricsRuntimeMBean
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionResourceMetricsRuntimeMBean.html
PartitionRuntimeMBean
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionRuntimeMBean.html
属性のGetter説明
isRCMMetricsDataAvailable()Checks whether RCMメトリックデータがこのパーティションで利用可能かどうかを確認する。
getCpuTimeNanos()パーティションに関わる総CPU利用時間(nsec)
getAllocatedMemory()パーティションに割り当てられたメモリの総量(byte)。このメトリック値は時間がたつにつれて単調増加する。
getThreadCount()現在パーティションに割り当てられているスレッドの個数
getTotalOpenedSocketCount()

getCurrentOpenSocketCount()
(上)パーティションに関わるオープンしているソケットの総数
(下)現在オープンしているソケットの個数
getNetworkBytesRead()

getNetworkBytesWritten()
(上)パーティションで開いているソケットから読み込んだ総バイト数
(下)パーティションで開いているソケットに書き込んだ総バイト数
getTotalOpenedFileCount()

getCurrentOpenFileCount()
(上)パーティションで開いているファイルの総数
(下)パーティションで現在開いているファイルの個数
getFileBytesRead()

getFileBytesWritten()
(上)パーティションで開いているファイルから読み込んだ総バイト数
(下)パーティションで開いているファイルに書き込んだ総バイト数
getTotalOpenedFileDescriptorCount()

getCurrentOpenFileDescriptorCount()
(上)パーティションで開いているファイル識別子の総数
(下)パーティションで現在開いているファイル識別子の個数
getRetainedHeapHistoricalData()パーティションに保持されるヒープメモリ使用量の履歴データのスナップショットを返す。データはパーティションで保持されたヒープの利用状況の時系列データのため、2次元配列として返す。配列内の各項目は、[timestamp (long), retainedHeap (long) ]の値の組み合わせ。
getCpuUtilizationHistoricalData()パーティションのCPU使用率の履歴データのスナップショットを返す。CPU使用率は、WebLogic Serverで’使用可能なCPUに対する、パーティションが利用したCPUの割合を示す。
パーティションのCPU利用率は時系列データなので、2次元配列として返す。配列内の各項目は、[timestamp (long), cpuUsage(long)]の値の組み合わせ。
PartitionMBean.RCMHistoricalDataBufferLimit属性がヒープやCPUのデータ配列のサイズを制限するということにご注意ください。
WebLogic Server MBean Reference
PartitionMBean.RCMHistoricalDataBufferLimit
http://docs.oracle.com/middleware/1221/wls/WLMBR/mbeans/PartitionMBean.html#RCMHistoricalDataBufferLimit

Java Flight Recorder

WLDFはJava Flight Recorderと統合し、WebLogic ServerのイベントをJVM記録に含めることができるようになっています。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Using WLDF with Java Flight Recorder
http://docs.oracle.com/middleware/1221/wls/WLDFC/using_flightrecorder.htm#WLDFC423
パーティションの変わりに実行されたワークのコンテキストで生成されたWebLogic ServerイベントにはパーティションIDとパーティション名がタグ付けされています。これらのイベントとFlight RecordingデータはWebLogic Serverシステム管理者だけが利用できます。

Conclusion

WLDFは、トラブルシューティングや診断タスクで非常に役に立つ様々なタイプの監視データを収集、アクセスするための豊富なツール群を提供します。このブログエントリでは、パーティション管理者のためのWLDFの入門情報をご紹介しました。深掘りしてこれらの機能を確認し、本番環境で活用されることをお勧めします。その他の詳細情報は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
http://docs.oracle.com/middleware/1221/wls/WLDFC/
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Monitoring and Debugging Partitions
http://docs.oracle.com/middleware/1221/wls/WLSMT/monitoring.htm#WLSMT639

2015年11月16日

[WLS, Java, FMW] Application MBeans Visibility in Oracle WebLogic Server 12.2.1

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle

Oracle WebLogic Server (WLS) 12.2.1では、 Multi-Tenancy (WLS MT)と呼ばれる機能をサポートしています。WLS MTではパーティション、パーティション管理者、パーティションリソースというコンセプトが導入されました。ドメイン中のリソース、例えばMBeanにアクセスする際にパーティション分離を強制します。WLS管理者はドメインやパーティションのMBeanを見ることができますが、パーティション管理者だけでなく他のパーティションロールは自身のパーティションにあるMBeanしか見ることはできません。

このエントリでは、アプリケーションMBeanの可視性サポートを説明して、WLS MT 12.2.1のパーティション分離を紹介します。この説明には以下の内容をふくみます
  • WLS MTでのアプリケーションMBeanの可視性に関する概要
  • どのMBeanがWLS MBeanServerに登録され、どのMBeanがWLS管理者もしくはパーティション管理者から見えるのかを説明するシンプルなユーザーケース
  • 詳細情報の参考記事へのリンク
このエントリで取り上げるユースケースは以下のエントリで作成したドメインを基にしています。
Create WebLogic Server Domain with Partitions using WLST in 12.2.1
https://blogs.oracle.com/WebLogicServer/entry/create_weblogic_server_domain_with
http://orablogs-jp.blogspot.jp/2015/11/create-weblogic-server-domain-with.html 
このエントリでは、以下の内容を説明しています。
  • ドメイントポロジの概要紹介
  • ドメインやパーティションへのアプリケーションデプロイ方法の説明
  • JMXクライアントからグローバル/ドメインURLやパーティション固有のURLで、アプリケーションMBeanにアクセスする方法の説明
  • デバッグ、ロギングの有効化方法の説明

1. Overview

アプリケーションをパーティション毎にWebLogic Serverにデプロイできるので、アプリケーションを複数のパーティションに対して複数配置します。WebLogic Serverには以下のMBeanServerがあります。
  • Domain Runtime MBeanServer
  • Runtime MBeanServer
各MBeanServerをすべてのパーティション用に使うことができます。WebLogic Serverはアプリケーションが各MBeanServerに登録したMBeanが各パーティションで一意であることを保証する必要があります。

WLS MTでのアプリケーションMBeanの可視性をいくつかのパートで説明します。
  • Partition Isolation
  • Application MBeans Registration
  • Query Application MBeans
  • Access Application MBeans

1.1 Partition Isolation

WLS管理者はパーティションMBeanを見ることができますが、パーティション管理者はドメインや他のパーティションのMBeanを見ることはできません。

1.2 Application MBeans Registration

アプリケーションをパーティションにデプロイする間にアプリケーションMBeanを登録します。WebLogic ServerはアプリケーションMBeanをWLS MBeanServerに登録する際に、パーティション固有のキー(例:Partition=<パーティション名>)をMBean Object Namesに追加します。こうして、増加したアプリケーションから登録された場合に、MBeanオブジェクト名が一意になることを保証します。

右図では、ドメインやパーティションのWLS MBeanServerに登録した際にアプリケーションMBean Object Nameが異なるさまを示しています。


右図ではWebLogicドメインとアプリケーションがあることを示しています。

WebLogicドメインは2個のパーティション(cokeとpepsi)で構成されています。

アプリケーションデプロイ中にアプリケーションがMBeanを登録します(例:testDomain:type=testType)。

アプリケーションをWebLogicドメイン、cokeパーティション、pepsiパーティションにデプロイします。WLS MBeanServerインスタンスはドメイン、cokeパーティション、pepsiパーティションが共有しています。
3回のアプリケーションデプロイメントの結果、3個のアプリケーションMBeanが同じMBeanServerに登録されています。
  • ドメイン所属のMBean:          testDomain:type=testType
  • cokeパーティション所属のMBean: testDomain:Partition=cokePartition,type=testType
  • pepsiパーティション所属のMBean: testDomain:Partition=pepsiPartition,type=testType
パーティションに属するMBeanには、ObjectNameのPartitionキープロパティが含まれています。

1.3 Query Application MBeans

WebLogic WLSTやJConsoleといったJMXクライアントでグローバル/ドメインURLやパーティション固有のURLに接続し、WebLogic MBeanServerに対しクエリを実行すると、異なるクエリ結果が返ってきます。
  • グローバル/ドメインURLに接続する場合、パーティション所属のアプリケーションMBeanは接続したJMXクライアントから見える。
  • パーティション固有のURLに接続する場合、WebLogic Serverがクエリ結果にフィルタを掛け、パーティション所属のアプリケーションMBeanのみ返す。ドメインや他パーティション所属のMBeanは見えない。

1.4 Access Application MBeans

WebLogic WLSTやJConsoleといったJMXクライアントがパーティション固有のURLに接続し、 getAttribute(<MBean ObjectName>, <attributeName>)のようなJMXの操作を実行すると、実のところ異なるMBeanに対してJMX操作を実行します。
  • グローバル/ドメインURLに接続する場合、ドメイン所属のMBean(MBean ObjectNameでPartitionキープロパティのないMBean)のgetAttribute()を呼び出す
  • パーティション固有のURLに接続する場合、パーティション所属のMBean(MBean ObjectNameでPartitionキープロパティがあるMBean)のgetAttribute()を呼び出す

2. Use case

それでは、MBeanの可視性がWebLogic Server 12.2.1のMultitenancyでパーティション分離をサポートするためにどのように作用するのか説明します。

2.1 Domain with Partitions

以下のエントリで、2個のパーティション(cokeとpepsi)を持つドメインを作成しています。
Create WebLogic Server Domain with Partitions using WLST in 12.2.1
https://blogs.oracle.com/WebLogicServer/entry/create_weblogic_server_domain_with
http://orablogs-jp.blogspot.jp/2015/11/create-weblogic-server-domain-with.html 
このドメインを再度このエントリのユースケースのために利用します。以下はドメイントポロジのサマリです。
  • ドメインは1個の管理サーバ(admin)、cokeとpepsiというパーティションで構成されている。
  • cokeパーティションには1個のリソースグループ (coke-rg1) を含み、仮想ターゲット(coke-vt)に向けられている
  • pepsiパーティションには1個のリソースグループ (pepsi-rg1) を含み、仮想ターゲット(pepsi-vt)に向けられている
より具体的に、各ドメイン/パーティションには以下の値で構成されています。
Domain NameUser NamePassword
Domainbase_domainweblogicwelcome1
Coke Partitioncokemtadmin1welcome1
Pepsi Partitionpepsimtadmin2welcome2
このドメイン作成方法の詳細は上記リンクをご覧ください。

2.2 Application deployment

ドメインをセットアップして開始し、アプリケーション"helloTenant.ear"をドメインにデプロイします。パーティションcokeのリソースグループcoke-rg1とパーティションpepsiのリソースグループpepsi-rg1にもデプロイします。デプロイはWLST、Fusion Middleware ControlといったWebLogic Serverのツールで可能です。以下はドメインとパーティションにアプリケーションをデプロイするためのWLSTコマンドの例です。
startEdit()
deploy(appName='helloTenant',target='admin,path='${path-to-the-ear-file}/helloTenant.ear')
deploy(appName='helloTenant-coke',partition='coke',resourceGroup='coke-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
deploy(appName='helloTenant-pepsi',partition='pepsi',resourceGroup='pepsi-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
save()
activate()
別のWLSデプロイメントツールについては、Referenceセクションをご覧ください。

2.3 Access Application MBeans

アプリケーションデプロイメントの間に、アプリケーションMBeanがWebLogic Server MBeanServerに登録されます。[1.2 Application MBean Registration]でお伝えした通り、1個のアプリケーションしかないにもかかわらず、複数のMBeanが登録されています。

アプリケーションMBeansにアクセスするには複数の方法があります。
  • WLST
  • JConsole
  • JSR 160 apis

2.3.1 WLST

WebLogic Scripting Tool (WLST) はコマンドラインスクリプティングインターフェースで、システム管理者やオペレータがWebLogic Serverインスタンスやドメインを監視・管理するために使います。WLSTを開始するには以下のコマンドを実行します。
$MW_HOME/oracle_common/common/bin/wlst.sh
WLSTが起動すると、ユーザーは接続URLを指定してサーバに接続することができます。以下は異なるアプリケーションMBean属性の値を示しています。WebLogic Server管理者やパーティション管理者が異なる接続URLを使った際には異なるアプリケーションMBean属性値が表示されます。

2.3.1.1 WLS administrator

WebLogic Server管理者 'weblogic' は以下の接続コマンドを使ってドメインに接続します。
connect("weblogic", "welcome1", "t3://localhost:7001")
下図はWebLogic Server MBeanServerに登録された3個のMBeanを示しています。なお、ドメイン名はtest.domain、各MBeanのPartitionName属性値は以下の通りです。
  • test.domain:Partition=coke,type=testType,name=testName
    • パーティションcokeに属している。PartitionName属性値はcoke
  • test.domain:Partition=pepsi,type=testType,name=testName
    • パーティションpepsiに属している。PartitionName属性値はpepsi
  • test.domain:type=testType,name=testName
    • ドメインに属している。ObjectNameのPartitionキープロパティはない。PartitionName属性はDOMAIN
パーティション所属のMBeanにはObjectName中にPartitionキープロパティがあります。パーティションコンテキストに登録する際にWebLogic Serverが内部でPartitionキープロパティを追加します。


2.3.1.2 Partition administrator for coke

同様に、パーティションcokeの管理者mtadmin1はパーティションcokeに接続できます。接続URLは仮想ターゲットcoke-vt(<Domain_Home>/config/config.xmlをチェックしてください)で定義されたURI接頭辞である/cokeを使います。
connect("mtadmin1", "welcome1", "t3://localhost:7001/coke")
下図のように、パーティションcokeに接続すると、1個だけMBeanが表示されます。
test.domain:type=testType,name=testName
PartitionキープロパティがObjectNameにありませんが、このMBeanはパーティションcokeに属しています。PartitionName属性値はcokeです。

2.3.1.3 Partition administrator for pepsi

同様に、パーティションpepsiの管理者mtadmin2はパーティションpepsiに接続できます。接続URLは仮想ターゲットpepsi-vt(<Domain_Home>/config/config.xmlをチェックしてください)で定義されたURI接頭辞である/pepsi を使います。
connect("mtadmin2", "welcome2", "t3://localhost:7001/pepsi")
下図のように、パーティションpepsiに接続すると、1個だけMBeanが表示されます。
test.domain:type=testType,name=testName
PartitionキープロパティがObjectNameにありませんが、パーティションcokeの管理者の場合と同様、このMBeanはパーティションpepsiに属しています。PartitionName属性値はpepsiです。

2.3.2 JConsole

JConsoleはJDKに組み込まれたGUIのツールで、Java Management Extensions (JMX)仕様に準拠した監視ツールです。JConsoleを使うと、MBeanServerに登録されたMBeanの概要をつかむことができます。

JConsoleを起動するには以下のコマンドを実行します。
$JAVA_HOME/bin/jconsole
-J-Djava.class.path=$JAVA_HOME/lib/jconsole.jar:
$JAVA_HOME/lib/tools.jar:$MW_HOME/wlserver/server/lib/wljmxclient.jar
 -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote
ここで<MW_HOME>はWebLogic Serverをインストールした場所です。

JConsoleが起動したら、WebLogic Server管理者やパーティション管理者は資格証明とJMXサービスURLを指定した後に、MBeanを確認することができます。

2.3.2.1 WLS administrator

WebLogic Server管理者weblogicはJMXサービスURLを指定して、WebLogic Server Runtime MBeamServerに以下のように接続します。
service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.runtime
WebLogic Server管理者が接続すると、JConsoleのMBeanツリーにはObjectNameにtest.domainを持つ3個のMBeanが表示されています。

下図の右ペインで示したObjectNameはパーティションcokeに属しており、Partitionキープロパティを有しています(Partition=coke)。


下図の場合パーティションpepsiに属するMBeanなので、Partitionキープロパティを有しています(Partition=pepsi)。



下図の場合、ドメインに属するMBeanなので、Partitionキープロパティはありません。



WebLogic Server管理者がWLSTで見たものとここで表示した結果は同じですね。

2.3.2.2 Partition administrator for coke

パーティション管理者mtadmin1は異なるJMXサービスURLをJConsoleに指定します。
service:jmx:t3://localhost:7001/coke/jndi/weblogic.management.mbeanservers.runtime
パーティション固有のJMXサービスURLを使って接続すると、パーティション管理者には1個のMBeanしか見えません。
test.domain:type=testType,name=testName
このMBeanはパーティションcokeに属しており、下図の通り、PartitionName属性値はcokeです。しかし、ObjectNameにPartitionキープロパティはありません。




2.3.2.3 Partition administrator for pepsi

パーティション管理者mtadmin2は異なるJMXサービスURLをJConsoleに指定します。
service:jmx:t3://localhost:7001/pepsi/pepsi/weblogic.management.mbeanservers.runtime
パーティション固有のJMXサービスURLを使って接続すると、パーティション管理者mtadmin2には1個のMBeanしか見えません。
test.domain:type=testType,name=testName
このMBeanはパーティションpepsiに属しており、下図の通り、PartitionName属性値はpepsiです。




2.3.3 JSR 160 APIs

JMXクライアントはJSR 160 APIを使ってMBeanServerに登録されたMBeanにアクセスすることができます。例えば以下のコードでは、サービスURLと環境をMBean属性に指定してJMXConnetorを取得しています。
import javax.management.*;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXServiceURL;
import javax.management.remote.JMXConnectorFactory;
import java.util.*

public class TestJMXConnection {
public static void main(String[] args) throws Exception {
JMXConnector jmxCon = null;
try {
// Connect to JMXConnector
JMXServiceURL serviceUrl = new JMXServiceURL(
"service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.runtime");
Hashtable env = new Hashtable();
env.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");
env.put(javax.naming.Context.SECURITY_PRINCIPAL, "weblogic");
env.put(javax.naming.Context.SECURITY_CREDENTIALS, "welcome1");
jmxCon = JMXConnectorFactory.newJMXConnector(serviceUrl, env);
jmxCon.connect();

// Access the MBean
MBeanServerConnection con = jmxCon.getMBeanServerConnection();
ObjectName oname = new ObjectName("test.domain:type=testType,name=testName,*");
Set<objectname> queryResults = (Set<objectname>)con.queryNames(oname, null);
for (ObjectName theName : queryResults) {
System.out.print("queryNames(): " + theName);
String partitionName = (String)con.getAttribute(theName, "PartitionName");
System.out.println(", Attribute PartitionName: " + partitionName);
}
} finally {
if (jmxCon != null)
jmxCon.close();
このコードをコンパイルして実行するためには、wljmxclient.jarをクラスパスに指定する必要があります。
$JAVA_HOME/bin/java -classpath $MW_HOME/wlserver/server/lib/wljmxclient.jar:. TestJMXConnection
以下のような結果が出力されるはずです。
Connecting to: service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.runtime
queryNames(): test.domain:Partition=pepsi,type=testType,name=testName, Attribute PartitionName: pepsi
queryNames(): test.domain:Partition=coke,type=testType,name=testName,  Attribute PartitionName: coke
queryNames(): test.domain:type=testType,name=testName, Attribute PartitionName: DOMAIN
パーティション管理者mtadmin1を使うようにコードを変更すると、以下のようになります。
JMXServiceURL serviceUrl = new JMXServiceURL(
"service:jmx:t3://localhost:7001/coke/jndi/weblogic.management.mbeanservers.runtime");
env.put(javax.naming.Context.SECURITY_PRINCIPAL, "mtadmin1");
env.put(javax.naming.Context.SECURITY_CREDENTIALS, "welcome1");
コードを実行すると、1個のMBeanしか返ってこないことがわかります。
Connecting to: service:jmx:t3://localhost:7001/coke/jndi/weblogic.management.mbeanservers.runtime
queryNames(): test.domain:type=testType,name=testName,  Attribute PartitionName: coke
同様の結果がパーティション管理者pepsiを使った場合に確認できるでしょう。パーティションpepsi固有のJMXサービスURLを指定すると、パーティションpepsiに属するMBean1個のみが返ってきます。

2.4 Enable logging/debugging flags

WebLogic Server 12.2.1でMBeanが正しい挙動を示さないことがあります。例えば、
  • MBeanのクエリを発行した際に、パーティション管理者がグローバルドメインや別のパーティションのMBeanを見ることができる。
  • JMX例外が発生する。例えば、MBeanにアクセスする際に、javax.management.InstanceNotFoundExceptionが発生する。
エラーの切り分けのために以下のことを試行してください。
  • JConsoleの接続問題の場合、JConsole起動時にコマンドラインに -debug を追加する
  • MBeanのクエリを発行すると、パーティション管理者がグローバルドメインや別パーティションのMBeanを見ることができる場合、
    • WLSTやJConsole、JSR 160 APIといったJMXクライアントから接続している場合、サービスのホスト名が<Domain_Home>/config/config.xmlの仮想ターゲットで定義したホスト名に一致することを確認する。
    • サービスURLのURI接頭辞が<Domain_Home>/config/config.xmlの仮想ターゲットで定義したURI接頭辞と一致することを確認する。
  • JMX例外が発生した場合、例えば、MBeanにアクセスする際に、javax.management.InstanceNotFoundExceptionが発生した場合
    • MBeanがパーティションに属する場合、パーティションを開始します。アプリケーションデプロイメントはパーティションが開始しないと実行されません。
    • 以下のオプションを追加して、サーバー始動時にデバッグフラグを有効にします。
      -Dweblogic.StdoutDebugEnabled=true -Dweblogic.log.LogSeverity=Debug -Dweblogic.log.LoggerSeverity=Debug -Dweblogic.debug.DebugPartitionJMX=true -Dweblogic.debug.DebugCIC=false 
    • 対象としている特定のMBean ObjectNameをサーバーログで探します。デバッグしているMBeanが正しくパーティション・コンテキストに登録されていることを確認します。MBeanオペレーションが正しくパーティションコンテキストで呼ばれていることを確認します。
    以下はMBean"test.domain:type=testType,name=testName" のMBean登録、queryNames()、getAttribute()の呼び出しに関連するデバッグメッセージの例です。
    <Oct 21, 2015 11:36:43 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:type=testType,name=testName in partition DOMAIN>
    <Oct 21, 2015 11:36:44 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:Partition=coke,type=testType,name=testName in partition coke>
    <Oct 21, 2015 11:36:45 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:Partition=pepsi,type=testType,name=testName in partition pepsi>
    <Oct 21, 2015 11:36:56 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <queryNames on MBean test.domain:Partition=coke,type=testType,name=testName,* in partition coke>
    <Oct 21, 2015 11:36:56 PM PDT> <Debug> <MBeanCIC> <BEA-000000> <getAttribute: MBean: test.domain:Partition=coke,type=testType,name=testName, CIC: (pId = 2d044835-3ca9-4928-915f-6bd1d158f490, pName = coke, appId = helloTenant$coke, appName = helloTenant, appVersion = null, mId = null, compName = null)>
    • パーティションコンテキストが正しくない理由を確認するため、上記のデバッグフラグに加え、以下のデバッグフラグを追加して、WebLogic Serverを始動してください。
      -Dweblogic.debug.DebugCIC=true. Once this flag is used, there are a lot of messages logged into the server log. Search for the messages logged by DebugCIC logger, like  ExecuteThread: '<thread id #>' for queue: 'weblogic.kernel.Default (self-tuning)'): Pushed 
      以下はDebugPartitionJMX ロガーがログ出力したメッセージの例です。
    <Oct 21, 2015, 23:59:34 PDT> INVCTXT (24-[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'): Pushed [(pId = 0, pName = DOMAIN, appId = null, appName = null, appVersion = null, mId = null, compName = null)] on top of [(pId = 0, pName = DOMAIN, appId = null, appName = null, appVersion = null, mId = null, compName = null)]. New size is [2]. Pushed by [weblogic.application.ComponentInvocationContextManagerImpl.pushComponentInvocationContext(ComponentInvocationContextManagerImpl.java:173)
    ...
    <Oct 21, 2015 11:59:34 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:type=testType,name=testName in partition DOMAIN>
    ...
    <Oct 21, 2015, 23:59:37 PDT> INVCTXT (29-[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'): Pushed [(pId = 2d044835-3ca9-4928-915f-6bd1d158f490, pName = coke, appId = helloTenant$coke, appName = helloTenant, appVersion = null, mId = null, compName = null)] on top of [(pId = 2d044835-3ca9-4928-915f-6bd1d158f490, pName = coke, appId = null, appName = null, appVersion = null, mId = null, compName = null)]. New size is [3]. Pushed by
    [weblogic.application.ComponentInvocationContextManagerImpl.pushComponentInvocationContext(ComponentInvocationContextManagerImpl.java:173)
    ...
    <Oct 21, 2015 11:59:37 PM PDT> <Debug> <PartitionJMX> <BEA-000000> <Calling register MBean test.domain:Partition=coke,type=testType,name=testName in partition coke>

3. Conclusion

WebLogic Server 12.2.1はMulti-Tenancy (MT)という新機能を提供しています。この機能を使って、パーティション分離が強制されています。アプリケーションをドメインやパーティションにデプロイできます。パーティションのユーザーは別のパーティションに所属するリソース(アプリケーションが登録したMBeanを含む)を見ることができません。このエントリでは、あるユースケースを使い、アプリケーションMBeanがパーティション分離が、MBeanの可視性でどのように影響するのかを御所階しました。詳細情報は、Referencesセクションをご覧ください。

4. References

Oracle® Fusion Middleware Installing and Configuring Oracle WebLogic Server and Coherence 12c (12.2.1) 
Creating and Configuring the WebLogic Domain
https://docs.oracle.com/middleware/1221/core/WLSIG/GUID-4AECC00D-782D-4E77-85DF-F74DD61391B4.htm#WLSIG281
Oracle® Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure 12c (12.2.1) 
Configuring the Oracle Fusion Middleware Infrastructure Domain
https://docs.oracle.com/middleware/1221/core/INFIN/GUID-CA80A6E9-8903-4E19-81D7-A3647A11D0A6.htm#INFIN280
Oracle® Fusion Middleware WLST Command Reference for WebLogic Server 12c (12.2.1)
https://docs.oracle.com/middleware/1221/wls/WLSTC/toc.htm
Java SE Monitoring and Management Guide
Using JConsole
http://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html
Managing WebLogic Server with JConsole
https://blogs.oracle.com/WebLogicServer/entry/managing_weblogic_servers_with
JSR 160: Java Management Extensions Remote JMX api
https://jcp.org/en/jsr/detail?id=160
Oracle® Fusion Middleware Administering Security for Oracle WebLogic Server 12.2.1 12c (12.2.1)
Configuring Security for a WebLogic Domain
http://docs.oracle.com/middleware/1221/wls/SECMG/conf-security-for-domain.htm#SECMG777
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server 12c (12.2.1)
Understanding WebLogic Server Deployment
https://docs.oracle.com/middleware/1221/wls/DEPGD/understanding.htm#DEPGD114

2015年11月14日

[Java, FMW, WLS] JMX Authorization policies

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/jmx_authorization

WebLogic Server 12.2.1でパーティションの概念が導入されたことで、MBeanのWebLogicユーザーへの認可方法に影響があります。これは、MBeanのスコープを以下のいずれかに設定できるからです。
  • ドメイン
  • パーティション
パーティションはWebLogicドメインのスライスであり、パーティション内でユーザーを定義することができます。あるパーティションのユーザーは別のパーティションのユーザーとは別のものであり、ドメインのユーザーとも別のものです。歴史的に、パーティションの概念がなかったときは、WebLogicドメインのユーザーは4個のロールをとることができます。すなわち、以下の4個のロールです。
  1. Administrator
  2. Deployer
  3. Monitor
  4. Operator
MBeanを認可できるか否かの基本的なルールを以下にまとめることができます。
  1. 任意のユーザーは暗号化されたMBean以外の任意のMBeanの読み取りが可能
  2. Administratorロールを持つユーザーは任意のMBeanの書き込み、実行が可能
  3. MBeanに指定ロールのみを許可するアノテーションが付いている限り、他のロール(Deployer、Monitor、Operator)を持つユーザーはMBeanにアクセス可能
@roleAllowed Deployer
Public class MyMBean {
    ... 
}
上記のケースの場合、Deployerロールを持つユーザーはこのMBeanへの書き込み、実行が可能ですが、Monitorロールを持つユーザーは当該MBeanに対し書き込み、実行はできません。

12.2.1では、Multitenancyが導入され、認可ルールが大きく変わりました。MBeanをドメインスコープ、パーティションスコープのいずれかに配置することができるようになっています。このスコープは"owned by(所有される)"と呼ばれることがあります。例えば、12.2.1ではDomainMBeanはMBeanがMBeanツリーのドメインレベルにあるため、ドメインが所有しています。WebLogic ServerのMBeansをツリー状の構造で表現してみると以下のような感じになります。

上図は、WebLogic ServerのMBeanをパーティションスコープもしくはドメインスコープに設定する方法を表現しています。 パーティションをWebLogicドメイン中に作成した場合、当該パーティションを表す、PartitionMBeanと命名した構成MBeanを作成します。上図をよく見ると、PartitionMBeanがパーティションスコープではなく、ドメインスコープに配置されていることがわかります。PartitionMBeanの下の任意のMBeanはパーティションスコープです。

それゆえ、パーティションユーザーがMBeanがMBeanツリーのどこにあるか次第でMBeanにアクセスできるかどうかが決まります。MBeanツリーのMBeanの場所によって、当該MBeanがパーティションスコープなのか、ドメインスコープなのかが定まります。ドメインユーザーはパーティションスコープのMBeanへの書き込み、実行が可能ですが、パーティションユーザーは、明示的にアノテーションが付加されていない限り、MBeanへの書き込み、実行はできません。

12.2.1では、@ownerという新たなアノテーションを導入しました。これは場所に基づいたMBeanの所有権の動作を明示的に指定された所有権にオーバーライドします。@ownerには以下の3個の値を設定できます。
  • Domain
    • @owner Domain アノテーションを付加すると、MBeanツリーでの場所にかかわらず、ドメインが所有するMBeanとしてオーバーライドされます。
  • Partition
    • @owner Partition アノテーションを付加すると、MBeanツリーでの場所にかかわらず、パーティションが所有するMBeanとしてオーバーライドされます。
  • Context
    • @owner Context アノテーションを付加すると、MBeanにアクセスしようとしているユーザーのログインコンテキストに基づいて、MBeanの所有権を変更します。
      • ユーザーがドメインコンテキストからMBeanへアクセスしようとしている場合、MBeanは@owner Domainとして振る舞います。
      • ユーザーがパーティションコンテキストからMBeanへアクセスしようとしている場合、MBeanは@owner Partitionとして振る舞います。
MBeanにドメインユーザーもパーティションユーザーもアクセスする必要がある場合、@owner Context は特に有用です。MBeanはドメインとパーティションの間で共有されているMBeanのように振る舞います。MBeanツリーでドメインスコープのMBeanに@owner Contextを付加した場合、特定パーティションユーザーではなく、全パーティションのユーザーがMBeanに対して書き込みや実行をすることができます。特定パーティションのユーザーだけを選択してドメインスコープのMBeanにアクセスさせる方法はありません。

MBeanのきめ細かい管理のために、MBeanの各属性、各オペレーションに対し @owner を付加することができます。MBeanインターフェースに @owner を付けると、当該MBeanのすべての属性やオペレーションに @owner を付加したように振る舞います。

Example usage

以下のようにMBeanへアノテーションを付加することで、Deployerロールを持つドメインユーザーやパーティションユーザーはDomainRuntimeMBeanのオペレーションや属性にアクセスすることができます。
/**
* @roleAllowed Deployer
* @owner Context
*/

public interface DomainRuntimeMBean

Authorization’s relation to visibility of an MBean

12.2.1では、Muititenancyの導入に伴い、どのMBeanをユーザーが見ることができるか、という点で変更があります。すべてのMBeanがユーザーに見えるわけではありません。MBeanがエンドユーザーに見える場合は、認可ルールが適用されています。WebLogic Server 12.2.1でのVisibilityルールの詳細については、以下のエントリをご覧ください。
Application MBeans Visibility in Oracle WebLogic Server 12.2.1
https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle
http://orablogs-jp.blogspot.jp/2015/11/application-mbeans-visibility-in-oracle.html

Default Security Policies in 12.2.1

  • Administratorロールを持つドメインユーザーは、ドメインおよびパーティション全体のすべてのMBeanに対するフルアクセス権があります。
  • MBean属性のGetterとlookupXXXオペレーションは、ドメインやパーティションの任意のユーザーに対して認可されます。このときアノテーションは不要です。
  • ドメインスコープのMBeanの属性のSetter、オペレーションにパーティションユーザーがアクセスする必要がある場合、@owner Contextをアノテーションで付加する必要があります。
  • MBeanを所有するパーティションの場合、当該パーティションのユーザーがアクセス可能にできるようにするために @owner アノテーションを付ける必要はありません。
  • 別のロール(Deployer、Monitor、Operator)を持っているドメインユーザーがドメインスコープのMBeanにアクセスする必要がある場合、 @roleAllowed アノテーションが付加されていなければなりません。Domain Administratorとは異なり、これらのユーザーはパーティションスコープのMBeanではなく、ドメインスコープのMBeanへのみアクセスできます。
  • Administratorロールを有するパーティションのユーザーは、当該パーティションの任意のMBeanにアクセスすることができますが、別のパーティションのMBeanにはアクセスできません。これはVisibilityルールによって保護されています。
  • Application MBeans Visibility in Oracle WebLogic Server 12.2.1 https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle
  • パーティションユーザーはドメインユーザーと同様のロール(Administrator、Deployer、Monitor、Operator)を持つことができます。
  • 別のロール(Deployer、Monitor、Operator)を持っているパーティションのユーザーがパーティションスコープのMBeanにアクセス(書き込み、実行)する必要がある場合、MBeanに @roleAllowed のアノテーションを付加する必要があります。

Summary of Authorization rules for users in Weblogic 12.2.1

Table 1: WLS MBeans without any @roleAllowed annotation 
Table 2: WLS MBeans with @roleAllowed annotation. This annotation can appear on MBean Interface, Attribute or Operation
  • Domain MBean: ドメインスコープにあるMBeanで、@owner Domain もしくは、 @owner Contextでアノテーションされている。サブジェクトはドメインContextにある。
  • Partition MBean: パーティションスコープにあるMBeanで、@owner Partition もしくは、 @owner Contextでアノテーションされている。MBeanにアクセスすると、サブジェクトはPartitionコンテキストにある。
Table 3: Previlege of Different Domain Roles
Table 4: Privilege of Different Partition Roles

[FMW, WLS, Java] Create WebLogic Server Domain with Partitions using WLST in 12.2.1

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/create_weblogic_server_domain_with

Oracle WebLogic Server 12.2.1ではMultitenancyをサポートしています。WebLogic Server Multitenancyでは、WebLogic Serverをドメインだけでなく、一つ以上のパーティションを使って構成することができます。パーティションにはWebLogic Server Multitenancyで導入された新たな要素(リソースグループ、リソースグループテンプレート、仮想ターゲットなど)が含まれています。パーティションを持つドメインを構成する場合、通常のWebLogicドメインの構成に比べて追加の手順が必要です。こうした新しいWebLogic Server Multitenancyに関連するコンセプトは、末尾のReferencesセクションに記載のドキュメントをご覧ください。

OracleはFusion Middleware Control(FMWC)で(Restricted JRFテンプレートを使い)WebLogicドメインを作成することを推奨していますが、WLSTを使ってWebLogic Serverこのエントリでは、2個のパーティションを持つWebLogicドメインをWLSTで作成する方法をご紹介します。
Using Fusion Middleware Control to Manage WebLogic Server
http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/manage_wls_fmc/obe.html
Oracle® Fusion Middleware Domain Template Reference 12c (12.2.1)
Oracle Restricted JRF Template
https://docs.oracle.com/middleware/1221/wls/WLDTR/fmw_templates.htm#WLDTR524
Oracle® Fusion Middleware Oracle WebLogic Scripting Tool 12c Release 1 (12.1.1)
Creating WebLogic Domains Using WLST Offline
http://docs.oracle.com/cd/E24329_01/web.1211/e24491/domains.htm#WLSTG156

1.Domain Topology

このエントリでは、以下のような構成のドメインを作成します。
  • adminという1個の管理サーバと、パーティションcoke、パーティションpepsiがある
  • パーティションcokeには、リソースグループcoke-rg1があり、仮想ターゲットcoke-vtに向けられている
  • パーティションpepsiには、リソースグループpepsi-rg1があり、仮想ターゲットpepsi-vtに向けられている
  • アプリケーションhelloTenant.earをドメイン、パーティションcokeのリソースグループcoke-rg1、パーティションpepsiのリソースグループpepsi-rg1にデプロイする。
ドメイントポロジーは以下のようになっています。
  • ドメイン
    • セキュリティ構成
      • レルム:myrealm
      • レルム:coke_realm
      • レルム:pepsi_realm
    • Server: admin(管理サーバ)
    • 仮想ターゲット:coke-vt
    • 仮想ターゲット:pepsi-vt
    • パーティション:coke
      • リソースグループ:coke-rg1
        • アプリケーションデプロイメント:helloTenant-coke
        • デフォルトターゲット:coke-vt
    • パーティション:pepsi
      • リソースグループ:pepsi-rg1
        • アプリケーションデプロイメント:helloTenant-pepsi
        • デフォルトターゲット:pepsi-vt
    • アプリケーションデプロイメント:helloTenant
    このドメイントポロジーには、リソースグループテンプレートのような別のMultitenancy関連のコンセプトを含んでいないことにご注意ください。このエントリでは取り扱いません。別のMultitenancy関連のコンセプトについて知りたい方は、Referencesセクションをチェックしてください。

    2. Create a domain with partitions

    上記のトポロジーを有するドメインを作成するには、以下の手順が必要です。
    • 通常のWebLogicドメインを作成
    • ドメインを起動
    • ドメインにパーティションを作成
      • パーティション用セキュリティレルムを作成
      • パーティション用のユーザーを作成
      • セキュリティレルムのグループにユーザーを追加
      • 仮想ターゲットを作成
      • パーティションを作成
        • リソースグループの作成
        • 仮想ターゲットをデフォルトターゲットに設定
        • パーティション用のセキュリティIDD(アイデンティティドメイン)を設定
    • サーバを再起動
    • パーティションの開始
    詳細を以下でご紹介します。

    2.1 Create a traditional WLS domain

    構成ウィザードを使って通常のWebLogicドメインを作成することができます。コマンドスクリプトから構成ウィザードを起動します。
    sh $MW_Home/oracle_common/common/bin/config.sh
    設定はすべてデフォルトですが、ドメイン名、管理者ユーザー名、パスワードは以下のものを使います。
    • ドメイン名:base_domain
    • 管理者ユーザ名:weblogic
    • 管理者ユーザのパスワード:welcome1

    2.2 Start the domain

    cd $MW_Home/user_projects/domains/base_domain/
    sh startWebLogic.sh

    2.3 Create a partition: coke in a domain

    WLSTを開始するには以下の手順が必要です。以下のコマンドでWLSTを起動します。
    sh $MW_Home/oracle_common/common/bin/wlst.sh
    管理サーバadminに管理ユーザweblogicとその資格証明を使って接続してから、以下のWLSTコマンドのすべてを実行できます。
    connect("weblogic", "welcome1", "t3://localhost:7001")
    これで、パーティションcokeのセットアップのためのWLSTコマンド実行の準備ができました。パーティションcokeには以下の設定を使います。
    • パーティション名:coke
    • パーティション管理者ユーザ名:mtadmin1
    • パーティション管理者ユーザのパスワード:welcome1
    以下の手順で、パーティション用のセキュリティレルムとユーザーを作成します。

    2.3.1 Create a security realm for the partition 

    標準的なWebLogic ServerのAPIを使ってセキュリティレルムを作成します。
    edit()
    startEdit()
    realmName = 'coke_realm'
    security = cmo.getSecurityConfiguration()
    print 'realm name is ' + realmName
    realm = security.createRealm(realmName)
    # ATN
    atnp = realm.createAuthenticationProvider(
      'ATNPartition','weblogic.security.providers.authentication.DefaultAuthenticator')
    atna = realm.createAuthenticationProvider(
      'ATNAdmin','weblogic.security.providers.authentication.DefaultAuthenticator')
    # IA
    ia = realm.createAuthenticationProvider(
      'IA','weblogic.security.providers.authentication.DefaultIdentityAsserter')
    ia.setActiveTypes(['AuthenticatedUser'])
    # ATZ/Role
    realm.createRoleMapper(
      'Role','weblogic.security.providers.xacml.authorization.XACMLRoleMapper')
    realm.createAuthorizer(
      'ATZ','weblogic.security.providers.xacml.authorization.XACMLAuthorizer')
    # Adjudicator
    realm.createAdjudicator('ADJ','weblogic.security.providers.authorization.DefaultAdjudicator')
    # Auditor
    realm.createAuditor('AUD','weblogic.security.providers.audit.DefaultAuditor')
    
    # Cred Mapper
    realm.createCredentialMapper(
      'CM','weblogic.security.providers.credentials.DefaultCredentialMapper')
    # Cert Path
    realm.setCertPathBuilder(realm.createCertPathProvider(
      'CP','weblogic.security.providers.pk.WebLogicCertPathProvider'))
    # Password Validator
    pv = realm.createPasswordValidator('PV',
      'com.bea.security.providers.authentication.passwordvalidator.SystemPasswordValidator')
    pv.setMinPasswordLength(8)
    pv.setMinNumericOrSpecialCharacters(1)
    save()
    activate()

    2.3.2 Add a user and group to the security realm for the partition

    ユーザを作成し、ユーザをレルムのセキュリティグループに追加します。このユースケースでは、パーティションcokeの管理ユーザ名とパスワードはmtadmin1 と welcome1です。
    edit()
    startEdit()
    realmName = 'coke_realm'
    userName = 'mtadmin1'
    groupName = 'Administrators'
    print 'add user: realmName ' + realmName
    if realmName == 'DEFAULT_REALM':
      realm = cmo.getSecurityConfiguration().getDefaultRealm()
    else:
      realm = cmo.getSecurityConfiguration().lookupRealm(realmName)
    print "Creating user " + userName + " in realm: " + realm.getName()
    atn = realm.lookupAuthenticationProvider('ATNPartition')
    if atn.userExists(userName):
      print "User already exists."
    else:
      atn.createUser(userName, '${password}', realmName + ' Realm User')
    print "Done creating user. ${password}"
    print "Creating group " + groupName + " in realm: " + realm.getName()
    if atn.groupExists(groupName):
      print "Group already exists."
    else:
      atn.createGroup(groupName, realmName + ' Realm Group')
    if atn.isMember(groupName,userName,true) == 0:
      atn.addMemberToGroup(groupName, userName)
    else:
      print "User is already member of the group."
    save()
    activate()

    2.3.3 Create a virtual target for the partition

    この仮想ターゲットは管理サーバをターゲットにします。UriPrefixは /coke です。このurl接頭辞は、WebLogic ServerのMBeanServerへのJMX接続を作成するために使われます。
    edit()
    startEdit()
    vt = cmo.createVirtualTarget("coke-vt")
    vt.setHostNames(array(["localhost"],java.lang.String))
    vt.setUriPrefix("/coke")
    as = cmo.lookupServer("admin")
    vt.addTarget(as)
    save()
    activate()

    2.3.4 Create the partition: coke

    パーティション名はcokeです。パーティションcokeを仮想ターゲットcoke-vtにターゲット指定します。
    edit()
    startEdit()
    vt = cmo.lookupVirtualTarget("coke-vt")
    p = cmo.createPartition('coke')
    p.addAvailableTarget(vt)
    p.addDefaultTarget(vt)
    rg=p.createResourceGroup('coke-rg1')
    rg.addTarget(vt)
    realm = cmo.getSecurityConfiguration().lookupRealm("coke-realm")
    p.setRealm(realm)
    save()
    activate()

    2.3.5 Setup IDD for the partition

    パーティションのプライマリ・アイデンティティドメイン(IDD)を設定します。
    edit()
    startEdit()
    sec = cmo.getSecurityConfiguration()
    sec.setAdministrativeIdentityDomain("AdminIDD")
    realmName = 'coke_realm'
    realm = cmo.getSecurityConfiguration().lookupRealm(realmName)
    # ATN
    defAtnP = realm.lookupAuthenticationProvider('ATNPartition')
    defAtnP.setIdentityDomain('cokeIDD')
    defAtnA = realm.lookupAuthenticationProvider('ATNAdmin')
    defAtnA.setIdentityDomain("AdminIDD")
    # Partition
    pcoke= cmo.lookupPartition('coke')
    pcoke.setPrimaryIdentityDomain('cokeIDD')
    # Default realm
    realm = sec.getDefaultRealm()
    defAtn = realm.lookupAuthenticationProvider('DefaultAuthenticator')
    defAtn.setIdentityDomain("AdminIDD")
    save()
    activate()

    2.3.6 Restart the Server

    セキュリティ設定の変更を反映するため、WebLogic Serverを再起動します。

    2.3.7 Start the partition

    パーティションがリクエストを受け付けるようにするために、以下の手順が必要です。
    edit()
    startEdit()
    partitionBean=cmo.lookupPartition('coke')
    # start the partition (required)
    startPartitionWait(partitionBean)
    save()
    activate()

    2.4 Create another partition: pepsi in a domain

    2.3の手順を繰り返し、別のパーティションpepsiを作成します。ただし、以下の値はパーティションcokeと違うものを使います。
    • パーティション名:pepsi
    • パーティション管理者名:mtadmin2
    • パーティション管理者のパスワード:welcome2
    • セキュリティレルム:pepsi_realm
    • アイデンティティドメイン名:pepsiIDD
    • 仮想ターゲット名:pepsi-vt
    • リソースグループ名:pepsi-rg1

    2.5 Deploy User Application

    これでドメインが利用できるようになりましたので、アプリケーションのearファイルをデプロイしましょう。今回はhelloTenant.earというアプリケーションをWebLogic Serverドメイン、パーティションcoke、パーティションpepsiにデプロイします。
    edit()
    startEdit()
    deploy(appName='helloTenant',target='admin,path='${path-to-the-ear-file}/helloTenant.ear')
    deploy(appName='helloTenant-coke',partition='coke',resourceGroup='coke-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
    deploy(appName='helloTenant-pepsi',partition='pepsi',resourceGroup='pepsi-rg1',path='${path-to-the-ear-file}/helloTenant.ear')
    save()
    activate()

    2.6 Domain config file sample

    すべての手順が完了したら、$DOMAIN_HOME/config/config.xml(ドメイン構成ファイル)にはドメインやパーティションに必要なすべての情報が含まれています。以下はconfig.xmlのパーティションcokeに関連するスニペットの例です。
    <server>
      <name>admin</name>
      <listen-address>localhost</listen-address>
    </server>
    <configuration-version>12.2.1.0.0</configuration-version>
    <app-deployment>
      <name>helloTenant</name>
      <target>admin</target>
      <module-type>ear</module-type>
      <source-path>${path-to-the-ear-file}/helloTenant.ear</source-path>
      <security-dd-model>DDOnly</security-dd-model>
      <staging-mode xsi:nil="true"></staging-mode>
       <plan-staging-mode xsi:nil="true"></plan-staging-mode>
      <cache-in-app-directory>false</cache-in-app-directory>
    </app-deployment>
    <virtual-target>
      <name>coke-vt</name>
      <target>admin</target>
      <host-name>localhost</host-name>
      <uri-prefix>/coke</uri-prefix>
      <web-server>
        <web-server-log>
          <number-of-files-limited>false</number-of-files-limited>
        </web-server-log>
      </web-server>
    </virtual-target>
    <admin-server-name>admin</admin-server-name>
    <partition>
      <name>coke</name>
      <resource-group>
        <name>coke-rg1</name>
        <app-deployment>
          <name>helloTenant-coke</name>
          <module-type>ear</module-type>
          <source-path>${path-to-the-ear-file}/helloTenant.ear</source-path>
          <security-dd-model>DDOnly</security-dd-model>
          <staging-mode xsi:nil="true"></staging-mode>
          <plan-staging-mode xsi:nil="true"></plan-staging-mode>
          <cache-in-app-directory>false</cache-in-app-directory>
        </app-deployment>
        <target>coke-vt</target>
        <use-default-target>false</use-default-target>
      </resource-group>
      <default-target>coke-vt</default-target>
      <available-target>coke-vt</available-target>
      <realm>coke_realm</realm>
      <partition-id>2d044835-3ca9-4928-915f-6bd1d158f490</partition-id>
      <primary-identity-domain>cokeIDD</primary-identity-domain>
    </partition>
    パーティションpepsiの場合、パーティションpepsiに対応する<virtual-target>要素と<partition>要素がconfig.xmlに追加されています。

    これで、2個のパーティションを持つドメインを作成し、リクエストを受け付ける準備ができました。ユーザーはこのドメインにデプロイしたアプリケーションにアクセスすることができます。WebLogic Server 12.2.1 Multitenancy環境のMBeanServersに登録されたアプリケーションMBeanにアクセスする方法については、以下のエントリをご覧ください。
    Application MBeans Visibility in Oracle WebLogic Server 12.2.1
    https://blogs.oracle.com/WebLogicServer/entry/application_mbeans_visibility_in_oracle

    3. Debug Flags

    ドメイン作成時にエラーが発生した場合、以下のデバッグフラグを使って、エラーの切り分けが可能です。
    • セキュリティレルムの設定に関連するエラーの場合、以下のデバッグフラグを使ってWebLogic Serverを再起動します。
      -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugSecurity=true -Dweblogic.debug.DebugSecurityRealm=true
    • ドメインでのBean構成エラーに関連するエラーの場合、以下のデバッグフラグを使ってWebLogic Serverを再起動します。
      -Dweblogic.debug.DebugJMXCore=true -Dweblogic.debug.DebugJMXDomain=true
    • 編集セッションの問題に関連するエラーの場合、以下のデバッグフラグを使ってWebLogic Serverを再起動します。
      -Dweblogic.debug.DebugConfigurationEdit=true -Dweblogic.debug.DebugDeploymentService=true -Dweblogic.debug.DebugDeploymentServiceInternal=true -Dweblogic.debug.DebugDeploymentServiceTransportHttp=true

    4. Conclusion

    Oracle WebLogic Server 12.2.1のドメインにはパーティションを含めることができます。パーティションを持つドメインを作成するには、通常のWebLogicドメインを作成する手順に加え、さらに追加の手順が必要です。このエントリではWLSTを使ったドメイン作成方法をご紹介しました。パーティション付きのドメイン作成は、Fusion Middleware Controlを使って作成することも可能です。パーティション付きのドメイン作成方法は、Referencesセクションに列挙したドキュメントやエントリをご確認ください。

    5. References

    Oracle® Fusion Middleware Installing and Configuring Oracle WebLogic Server and Coherence 12c (12.2.1)
    Creating and Configuring the WebLogic Domain
    http://docs.oracle.com/middleware/1221/core/WLSIG/GUID-4AECC00D-782D-4E77-85DF-F74DD61391B4.htm#WLSIG283
    Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1
    https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy
    http://orablogs-jp.blogspot.jp/2015/11/domain-partitions-for-multi-tenancy-in.html
    Using Fusion Middleware Control to Manage WebLogic Server
    http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/manage_wls_fmc/obe.html
    Oracle® Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure 12c (12.2.1)
    Creating Database Schemas
    https://docs.oracle.com/middleware/1221/core/INFIN/GUID-CA80A6E9-8903-4E19-81D7-A3647A11D0A6.htm#INFIN356
    Oracle® Fusion Middleware Oracle WebLogic Scripting Tool 12c Release 1 (12.2.1)
    Creating WebLogic Domains Using WLST Offline
    http://docs.oracle.com/middleware/1221/wls/WLSTG/domains.htm#WLSTG156
    Oracle® Fusion Middleware Domain Template Reference 12c (12.2.1)
    Oracle Restricted JRF Template
    https://docs.oracle.com/middleware/1221/wls/WLDTR/fmw_templates.htm#WLDTR524
    Oracle® Fusion Middleware Administering Security for Oracle WebLogic Server 12.2.1 12c (12.2.1)
    Configuring Security for a WebLogic Domain
    http://docs.oracle.com/middleware/1221/wls/SECMG/conf-security-for-domain.htm#SECMG777
    Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server 12c (12.2.1)
    Understanding WebLogic Server Deployment
    https://docs.oracle.com/middleware/1221/wls/DEPGD/understanding.htm#DEPGD114
    WebLogic Server Debug Flags
    http://weblogic-wonders.com/weblogic/2010/11/18/weblogic-server-debug-flags/

    [WLS, FMW] Oracle WebLogic Server 12.2.1 Running on Docker Containers

    原文はこちら。
    https://blogs.oracle.com/WebLogicServer/entry/oracle_weblogic_server_12_21

    Oracle WebLogic Server 12.2.1はDockerコンテナ上での動作を保証しています。この動作検証・保証の一環として、Oracle WebLogic Server 12.2.1インストールイメージとOracle WebLogic Serverドメインイメージを作成するためのDockerファイルをGitHubにUpしました。
    WebLogic on Docker
    https://github.com/oracle/docker/tree/master/OracleWebLogic/
    これらのイメージは既存のOracle Linuxイメージの拡張として構築されています。
    oraclelinux - Docker Hub
    https://registry.hub.docker.com/_/oraclelinux/
    これを使う上での助けとなるよう、使い始めるにあたってのサンプルとして、DockerfilesとスクリプトをGitHubにアップしました。

    Dockerはユーザーが分散アプリケーションをビルド、パッケージ、リリース、実行することができるプラットフォームです。
    Docker
    https://www.docker.com/
    Dockerユーザーは自身が作成したアプリケーションや依存するライブラリやファイルをDockerイメージに固めます。DockerイメージはLinux環境で配布できる可搬性のあるアーティファクトで、この配布イメージを使ってコンテナを始動することができ、これによって同一ホストのOS上の別のコンテナ上で動作する別のアプリケーションとは分離して、アプリケーションを実行することができます。

    下表は種々のWebLogic Serverバージョンで動作保証されている組み合わせです。Dockerイメージを構築する場合には、これらのOracle WebLogic Server、JDK、Linux、Dockerのバージョンの組み合わせを使うことができます。
    Oracle WebLogic ServerのバージョンJDKのバージョンホストOSカーネルバージョンDockerのバージョン
    12.2.1.0.08Oracle Linux 6 UL 6+UEK Release 3 (3.8.13)1.7+
    12.2.1.0.08Oracle Linux 7 UL 0+UEK Release 3 (3.8.13) Or RHCK 3 (3.10)1.7+
    12.2.1.0.08RedHat Linux 7+RHCK 3 (3.10)1.7+
    12.1.3.0.07/8Oracle Linux 6 UL 5+UEK Release 3 (3.8.13)1.3.3+
    12.1.3.0.07/8Oracle Linux 7 UL 0+UEK Release 3 (3.8.13) Or RHCK 3 (3.10)1.3.3+
    12.1.3.0.07/8RedHat Linux 7+RHCK 3 (3.10)1.3.3+
    (訳注)
    RHCKとあるのは、Red Hat Compatible Kernel(Red Hat互換カーネル)の略です。

    この表に記載されている以外のLinuxホストで動作する、動作保証されているDockerコンテナのOracle WebLogic Serverをサポートします。ただし、Kernel 3.8.13以上でDockerコンテナをサポートするものに限ります。詳しくはSupport Statementをご覧ください。
    Support for Oracle WebLogic Server Running in Docker Containers on Non-Certified Linux Host Operating Systems (Doc ID 2017945.1)
    https://support.oracle.com/rs?type=doc&id=2017945.1
    現在のOracle WebLogic Serverのサポート対象構成に関する詳細は、以下のリンクをご覧ください。
    Supported Virtualization and Partitioning Technologies for Oracle Fusion Middleware
    http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.html
    これらのDockerfilesとスクリプトを使って、一つのホストOSもしくはVM上で動作する、開発、本番の両環境を含めて、クラスタ構成および非クラスタ構成のOracle WebLogic Serverのドメインを作成できます。 生成されたドメインの各サーバはそれぞれDockerコンテナで動作します。他のサーバと必要に応じて通信することができます。

    アプリケーションやサービスのコンテナ化は”Docker-way”に沿ったトポロジであり、このトポロジはすべてのリソース、共有ライブラリやデプロイメントを含む管理サーバのみを実行するよう設計されたコンテナで構成されています。これらのDockerコンテナは、すべて単一の物理または仮想サーバーのLinuxホスト、もしくは複数の物理または仮想サーバのLinuxホスト上に置くことができます。WebLogic Serverドメインを持つイメージを作成するためのGitHub上のDockerfilesを使い、これらの管理サーバコンテナを起動することができます。
    Dockerfilesやスクリプトの使い方に関するドキュメントは、OTNのホワイトペーパーをご覧ください。
    Oracle WebLogic Server on Docker Containers
    http://content.oracle.com/site/pd/fmw/products/CAF/weblogic-server/cnt2359150.pdf
    Oracle WebLogic Serverのビデオとデモでは、当社の動作検証作業の成果を紹介し、Dockerコンテナ上で動作するWebLogic Server 12.2.1のデモをご覧いただけます。
    WebLogic 12.2.1 on Docker Containers
    https://www.youtube.com/watch?v=cgf8wzXnmb4
    DockerコンテナでWebLogic Serverの異なる構成を実行された際のフィードバックをお待ちしております。

    2015年11月13日

    [Java] When is the next Java update?

    原文はこちら。
    https://blogs.oracle.com/java-platform-group/entry/when_is_the_next_java

    "Java update available -- a new version of Java is ready to be installed..."
    (Javaのアップデートが利用できます-- 新しいバージョンのJavaのインストール準備ができました)
    OracleのJava SEは、Oracle Critical Patch Update(以下CPU)のスケジュールでアップデートされます。
    Critical Patch Updates, Security Alerts and Third Party Bulletin
    http://www.oracle.com/technetwork/topics/security/alerts-086861.html
    これらのアップデートの日程は1年先の情報まで公開しており、このスケジュールは、システム管理者がシステム全体でソフトウェア管理する上で役立ちます。他の機能、セキュリティベースラインと組み合わせることで、クライアントシステムは、新しいセキュリティ更新プログラムを検出することができますし、アップデートを提供し、クライアントシステムへの攻撃を減少させることによって、クライアントシステムの動作を調整することができます。セキュリティベースラインを下回るバージョンが必要な場合、システム管理者はデプロイメントルールセットを使って互換性を管理することができます。

    The Security Baseline

    セキュリティベースラインは、Java 7 upadte 10(2012年12月)でJREの有効期限と組み合わさり、新しい挙動をするようになりました。
    Java™ SE Development Kit 7, Update 10 (JDK 7u10)
    http://www.oracle.com/technetwork/java/javase/7u10-relnotes-1880995.html
    これまでは、JDK 1.4以降、どのJavaバージョンに最新のセキュリティパッチが含まれているかを特定してきました。
    JDK 5.0u22 Release Notes
    Changes in 1.5.0_12
    http://www.oracle.com/technetwork/java/javase/releasenotes-142123.html#150_12
    各主要なJavaバージョン(Java 6、Java 7、Java 8)で異なるベースラインのバージョンがあり、JREは主として二つの方法で更新対象であるかどうかを識別します。
    • JREは定期的にセキュリティベースラインをチェックし、新しいバージョンが利用可能であるかどうかを確認します。セキュリティベースラインを下回っていることを検出すると、セキュリティベースライン要件を満たすバージョンのアップデートが必要と判断します。
    • この定期的な検査のスケジュールは、システム管理者が制御できます。
      What is Java Auto Update? How do I change notify settings?
      https://www.java.com/en/download/help/java_update.xml
    • クライアントマシンが何らかの理由でセキュリティベースラインに到達できない場合、最終的に組み込まれている有効期限に到達します。有効期限は、各リリースノートで公開されていますが、通常は次回の定期CPUの1ヶ月後です。
      Java Development Kit 8 Update Release Notes
      http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html
      この有効期限は組み込まれており、制御することはできません。
    CPUに加え、Patch Set Update (PSU) とよばれる別のリリースタイプがあります。これには重要度のそれほど高くない変更が追加されています。PSUのバージョンは数値上セキュリティベースラインより大きな値ですが、PSUには、セキュリティベースラインに対応するCPUとまったく同じ重要なパッチが含まれています。例えば、執筆時点では、セキュリティベースラインは1.8.0_65で、別のPSUである1.8.0_66には、追加の変更が含まれています。重要なパッチだけを適用したいのであれば、PSUに含まれる変更を適用する必要はありませんし、個別にテストすることができます。次の定期CPUでは、1.8.0_66からの変更が含まれます。

    What happens when the security baseline changes or the expiration date passes

    クライアントが現在のセキュリティベースラインを下回っていることを検出した場合、通常は2個のタスクを実行します。
    • エンドユーザーに対し、新しいアップデートをインストールするように促す
    • インストールされたJREに対する潜在的な攻撃面を減らす
    「JREの有効期限が切れた、もしくはセキュリティベースラインを下回ったか」という質問に対してH、RIA(Rich Internet Application Deployment Process)デプロイメントプロセスでこれらの変更を説明しています。
    Rich Internet Application Deployment Process
    http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_flow.html
    「このRIA用のルールは存在するか」という質問に対しては、プロンプトの管理やセキュリティベースラインを下回るJavaバージョンを利用する必要があるデスクトップ管理者は、デプロイメントルールセットを使って対応することができます。
    Deployment Rule Set by Example
    https://blogs.oracle.com/java-platform-group/entry/deployment_rule_set_by_example
    攻撃面の減少は(ブラウザを通じて)リッチ・インターネット・アプリケーションに適用されます。

    Planning for updates

    この先1年のCPUの予定が公開されているので、システム管理者はJavaのアップデートをクライアントシステムに展開する計画を事前に計画しておくべきです。デプロイメントルールセットを使って、種々の理由で最新のJava Runtime Environmentを利用できないアプリケーションについて、既知の安全なアプリケーションが特定の古いJREを使うことができるか、ホワイトリストに登録しておく必要があります。CPUはJava 6、Java 7でも商用製品のJava SE Advancedを通じて、その他の管理ツールとともに利用することができます。

    数多くの管理対象システムに対し、四半期毎にJavaを展開しなければならない管理者は、商用製品であるJava SE Advancedを検討されてもよいかと思います。Java SE Advancedでは、大規模にJavaを管理する上で使いやすいツールを提供しています。
    Oracle Java SE Advanced & Suite Products
    http://www.oracle.com/technetwork/jp/java/javaseproducts/overview/index.html(日本語)
    http://www.oracle.com/technetwork/java/javaseproducts/overview/index.html(英語)

    Additional Resources