[Security, Java, Support, WLS] CVE-2015-4852に対するパッチや回避策

Apache Commons Collectionライブラリに起因する脆弱性がセキュリティ・アドバイザリとして2015年11月10日(PST)に公開されましたが、その脆弱性に対応するパッチが出ています。
Oracle Security Alert for CVE-2015-4852
http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html
CVE-2015-4852 Patch Availability Document for Oracle WebLogic Server Component of Oracle Fusion Middleware (ドキュメントID 2075927.1)
https://support.oracle.com/rs?type=doc&id=2075927.1
パッチの適用が今すぐには難しい、という場合には、回避策が同じくMy Oracle Supportで公開されています。
CVE-2015-4852 Mitigation Recommendations for Oracle WebLogic Server Component of Oracle Fusion Middleware (ドキュメントID 2076338.1)
https://support.oracle.com/rs?type=doc&id=2076338.1
詳しくはMy Oracle Supportのドキュメントをご覧ください。

- 0 件のコメント:
カテゴリ , , ,

[Java, WLS, FMW] JMS 2.0 support in WebLogic Server 12.2.1

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/jms_2_0_support_in
Java EE 7サポートの一環として、WebLogic Server 12.2.1はJMS 2.0仕様をサポートしています。

JMS 2.0は2002年にversion 1.1がリリースされてから初めてのJMS仕様に対するアップデートです。あまりにも長い間変わらずに残っているAPIが瀕死で使われずに成長してきたと思う人がいるかもしれませんが、異なる実装の数でAPI標準の成功を判断するのであれば、JMSは最も成功したAPIの一つです。

JMS2.0では、強調は、他のエンタープライズJavaテクノロジに加えられた使いやすさの改善に追いつくこと力点を置いています。今ではEnterprise JavaBeansやJava Persistenceなどの技術が、十年前に比べてずっと簡単に使用できるのに対し、JMSは成功したものの冗長なAPIとして代わらずに残ってきました。

JMS2.0における唯一にして最大の変化は、メッセージ送受信のための新たなシンプルになった新しいAPIの導入です。これにより、開発者が記述しなければならないコードの量が少なくなっています。WebLogic Server自体で実行するアプリケーションのために、新しいAPIは、リソース注入（resource injection）をサポートしています。これを使うと、WebLogic Serverは、アプリケーションをずっと簡素化しながら、JMSオブジェクトの作成と管理の世話をすることができます。

JMS2.0の非同期送信、共有トピックサブスクリプションや配信遅延にも変更が入っています。これらはWebLogic Serverの既存機能ですが、今では改善された標準APIを使って利用することができます。

JMS 2.0についてもっと知りたい方は、以下の15分間の動画プレゼンテーションをご覧ください。
15 minute audio-visual slide presentation


以下のOTN技術記事2個をお読みください。
以下の製品ドキュメントもご一読ください。
Oracle® Fusion Middleware Developing JMS Applications for Oracle WebLogic Server 12c (12.2.1)
Understanding the Simplified API Programming Model
https://docs.oracle.com/middleware/1221/wls/JMSPG/simplified_api.htm#JMSPG1034
お急ぎですか？それであれば、以下のエントリをご覧ください。
Ten ways in which JMS 2.0 means writing less code
https://java.net/projects/jms-spec/pages/JMS20MeansLessCode

- 0 件のコメント:
カテゴリ ,

[WLS, FMW] Elasticity for Dynamic Clusters

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

Introducing Elasticity for Dynamic Clusters

WebLogic Server 12.1.2で動的クラスタのコンセプトを導入しました。このコンセプトでは管理対象サーバの構成が単一の共有テンプレートから離れたため、クラスタ構成の管理対象サーバの構成が非常にシンプルになり、動的にサーバをマシンリソースに割り当てることができ、最小限の構成でより一層のリソースの活用が可能になっています。
Oracle WebLogic Server 12.1.2（日本語）
http://docs.oracle.com/cd/E50629_01/wls/index.html
Oracle WebLogic Server 12.1.2 （英語）
http://docs.oracle.com/middleware/1212/wls/index.html
Oracle® Fusion Middleware  Administering Clusters for Oracle WebLogic Server  12c (12.2.1)
Dynamic Clusters
http://docs.oracle.com/middleware/1221/wls/CLUST/dynamic_clusters.htm#CLUST678
WebLogic Server 12.2.1では、動的クラスタのコンセプトに対し、Elasticity（弾力性）を導入して、ユーザーが識別した条件に基づいてスケールアップ、スケールダウンすることを可能にしています。特定の日時や様々なサーバメトリックからわかるパフォーマンスを基にして、クラスタのスケールを（管理者が対話的に）オンデマンドで実現します。

このエントリでは、WebLogic Server 12.2.1.0のElastic Dynamic Clustersという、WebLogic Serverが持つオンプレミスの柔軟性に対するパズルの次のピースの様々な側面を見ていきます。続くエントリで、動的クラスタを使った弾力性を達成するための様々な方法の詳細の検証をご紹介します。
Oracle WebLogic Server 12.2.1
http://docs.oracle.com/middleware/1221/wls/index.html

The WebLogic Server Elasticity Framework

下図はWebLogic Serverのための柔軟性をもたらすフレームワークへの様々な部分を示しています。

Elastic Services FrameworkはWebLogicドメインの管理サーバにある一連のサービス群であり、以下のもので構成されています。
OTDとのより緊密な連携が12.2.1で可能ですが、OTDサーバプールがDynamic Discoveryを有効にしている場合、OTDは必要に応じてクラスタ内の利用可能なサーバ群に対応することにご注意ください。

Configuring Elasticity for Dynamic Clusters

手始めに、新たな動的クラスタを構成し、既存の動的クラスタを調整して、DynamicServerMBeanに追加された新しいプロパティを活用して、クラスタが弾力境界を設定し、クラスタの挙動を制御します。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)
Configuring Dynamic Clusters
http://docs.oracle.com/middleware/1221/wls/ELAST/requirements.htm#ELAST530
構成できる新しいプロパティは以下のようなものがあります。
  • 開始時の動的クラスタサイズ
  • クラスタ伸縮時のクラスタサイズ最小・最大値
  • スケールイベント間に必要な「クールオフ」期間
クラスタ内の管理対象サーバのシャットダウンを管理する方法に関する、その他いろいろなプロパティがありますが、上記の設定は（何個のインスタンスをスケールアップ、スケールダウンするか、によって）クラスタの境界と、どのぐらいの頻度でスケールイベントが発生しうるかを管理・制御します。 Elastic Services Frameworkを使うと、動的クラスタが指定された最大インスタンス数まで拡張、最小インスタンス数まで縮小させることができます。

クールオフ期間とは、スケールイベントがあまりにも頻繁に発生しないように設計された安全のための機構です。スケールイベントが完了し、その効果が動的クラスタのパフォーマンス特性でわかる時間に設定しておくべきです。

言うまでもありませんが、こうした設定の値は注意して選択し、クラスタキャパシティの計画に合わせるべきです。

Scaling Dynamic Clusters

動的クラスタのスケールは以下の手段で実施できます。
  • オンデマンド（WebLogic Server管理コンソールやWLSTの利用）
  • WLDFポリシーやアクションを活用する、自動化されたカレンダーベースのスケジュールを利用
  • パフォーマンスメトリックに基づいた自動化されたWLDFポリシーの活用

On-Demand Scaling

WebLogic管理者は、必要に応じてオンデマンドで動的クラスタの拡張・縮小させることができます。

コンソールの場合、管理者は単純に所望のクラスタで稼働するサーバの総数を指定するだけです。コンソールはElastic Services Frameworkと対話し、動的クラスタの境界内で、設定に従いクラスタを伸縮させます。

Automated Scaling


動的クラスタのオンデマンドでの拡張・縮小に加え、WebLogic Serverの管理者は、WLDFのポリシーおよびアクションという機能を使い、自動化ポリシーを構成することができます（以前のリリースでは、Watch & Notifications Framework（監視および通知）として知られていました）。
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
通常は、スケール自動化はWLDFポリシーのペア（一つはクラスタのスケールアップ、もう一つはスケールダウン）から構成されています。各スケールポリシーは以下の要素から構成されています。
  • （オプション）（以前の”Watch Rule"（監視ルール））ポリシー式
  • スケジュール
  • スケールのアクション
スケール自動化ポリシーの作成のために、管理者は以下の作業が必要です。
詳細情報は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)
Configuring Policies and Actions
http://docs.oracle.com/middleware/1221/wls/ELAST/requirements.htm#ELAST580

Calendar Based Elastic Policies

12.2.1で、WLDFにcronふうのポリシー評価スケジューリング機能が導入されています。特定スケジュールに従ってMBeanを監視するポリシーは”スケジュールされた”ポリシーと呼びます。
カレンダーベースのポリシーは無条件でスケジュールに従って実行し、関連するアクションを実行するポリシーです。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1) 
Calendar Based Scaling
http://docs.oracle.com/middleware/1221/wls/ELAST/calendar_based_scaling.htm#ELAST522
スケールアクションと組合せると、動的クラスタを指定された時間に伸張・縮小することができるポリシーを作成できます。
それぞれのスケジュールされたポリシータイプには自身のスケジュールがあります。スケジュールは（一個の評価周期に紐付いていた以前のリリースとは異なり）カレンダー時間で構成され、以下のようなスケジュールパターンを作成することができます（パターンは以下に限定するものではありません）。
  • 定期的なパターンベースの間隔（例：毎時5分、毎分の30秒）
  • 曜日や月日（例：月曜、水曜、金曜の午前8時、毎月15日と30日）
  • 年の特定の日時（例：12月26日午前8時［EST］）
そのため、例えば、オンライン小売店舗の場合、クリスマス休暇期間のポリシー・ペアを以下のように構成することができます。
  • 「ブラックフライデー」ポリシー
    • クリスマスのお買い物シーズンの増加する需要に合わせ、必要な個数のインスタンスだけクラスタを伸張する
  • 別のポリシー
    • クリスマスのお買い物シーズンが終わった12月25日には、クラスタを縮小する

Performance-based Elastic Policies

カレンダーベースのスケジューリングに加え、12.2.1のWLDFでは成することができます。サーバ内（"server-scoped"）もしくはクラスタ内（"cluster-scoped"）のパフォーマンス条件に基づいてスケールさせるポリシーを作成することができます。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1) 
Policy Based Scaling
http://docs.oracle.com/middleware/1221/wls/ELAST/policy_based_scaling.htm#ELAST525 
WebLogic Serverでサポートしている様々なランタイムメトリックに基づいてポリシーを作成することができます。WLDFでは、パフォーマンスベースのポリシー作成に役立つ事前パッケージ済み、パラメータ化済みのSmart Rulesと呼ばれる関数群も標準で提供しています。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)  
Introducing Smart Rules
http://docs.oracle.com/middleware/1221/wls/ELAST/policy_based_scaling.htm#ELAST535
 クラスタスコープのSmart Ruleを使うと、特定のタイムウィンドウにおけるクラスタ全体でのパフォーマンスメトリックのトレンドを見ることができますし、スケールアクションと組合せた場合、指定した条件に基づいてクラスタの伸張・縮小が可能です。
Smart Ruleで利用可能なメトリックの例には以下のようなものがあります。
  • スループット（秒間リクエスト）
  • JVMのヒープの空き具合（パーセンテージ）
  • プロセスCPU負荷
  • 保留中のユーザーリクエスト
  • アイドルスレッド数
  • スレッドプールのキュー長
さらに、WLDFでは汎用的なSmart Ruleを提供しており、これを使うとご自身のJMXベースのメトリックに基づいたポリシーを作成することができます。Smart Ruleのリファレンスは以下からご覧ください。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Smart Rule Reference
http://docs.oracle.com/middleware/1221/wls/WLDFC/appendix_smartrules.htm#WLDFC649
そして、Smart Ruleが要件に合わない場合、自身でポリシー式を作成できます。12.2.1では、WLDFはJava EL 3.0をポリシー式言語として活用しているため、JavaBeanオブジェクトや関数をベースにしたカスタムのポリシー式を作成することができます。しかも標準で提供されるSmart Ruleも含めて作成できます。
JSR-000341 Expression Language 3.0
https://jcp.org/aboutJava/communityprocess/final/jsr341/index.html
The Java™ Tutorials - JavaBeans™
https://docs.oracle.com/javase/tutorial/javabeans/
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Configuring Policies
http://docs.oracle.com/middleware/1221/wls/WLDFC/config_watches.htm#WLDFC194
WLDF Beans and Functions Referencehttp://docs.oracle.com/middleware/1221/wls/WLDFC/appendix_beans.htm#WLDFC723

Provisioning and Safeguards with Elasticity

スケール中に仮想マシンの追加・削除が必要なのはどういう場合でしょうか。WebLogic Server 12.2.1ではスクリプトインターセプタを使ってスケールイベントに参加することができます。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)
Overview of the Script Interceptor
http://docs.oracle.com/middleware/1221/wls/ELAST/script_interceptor.htm#ELAST534 
スクリプトインターセプタはコールアウトフッキングを提供します。その箇所で、クラスタでスケールイベントが発生したタイミングで呼び出されるカスタムのシェルスクリプトもしくはその他の実行ファイルを供給することができます。この方法で、3rdパーティの仮装マシンハイパーバイザと対話するスクリプトを書いてスケールアップの前に仮想マシンを追加したり、スケールアウト後に仮想マシンを除去、再割り当てすることができます。

WebLogic Serverは管理者に対し、データソース・インターセプタ機能を使ってスケールアップイベント時にデータベースキャパシティが過負荷にならないようにする機能も提供します。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1) 
Configuring the Data Source Interceptor
http://docs.oracle.com/middleware/1221/wls/ELAST/datasource_interceptor.htm#ELAST528 
データソースインターセプタを使うと、最大接続制約をもつデータソースURLやURLパターン群を関連づけることで、許容されているデータベース接続数の最大値を設定することができます。スケールアップのリクエストがクラスタに対して発行された場合、（追加のサーバキャパシティがある場合に）データソースインターセプタはクラスタに対する新しい最大接続要件がどういうものかを確認し、スケールアップの結果データベースの過負荷が引き起こされそうであれば、そのスケールアップリクエストを拒否します。依然としてデータベース活用に対する適切なキャパシティ計画が必要ではありますが、クラスタのスケールアップによってデータベースに過負荷が及ばないことを確実にするために、実行時にいくつかの健全性チェックに配置することができます。

Integration with Oracle Traffic Director

ElasticityフレームワークはWebLogic Server 12.2.1のライフサイクル管理サービスを通じてOTDとも統合されています。
Oracle® Fusion Middleware  Using WebLogic Server Multitenant  12c (12.2.1)
End-to-End Lifecycle Management
http://docs.oracle.com/middleware/1221/wls/WLSMT/concepts.htm#WLSMT725 
スケールイベントが発生すると、Elasticityフレームワークがライフサイクル管理サービスと対話してOTDにスケールイベントを通知し、その結果通知に従いOTDはルーティングテーブルを更新することができます。
例えばスケールアップイベントが発生した場合、OTDは候補サーバに通知し、それに従ってサーバプールを調整します。
スケールダウンの場合、ライフサイクル管理サービスがOTDにどのインスタンスが減るのかを通知するので、OTDは新しいリクエストをスケールダウン対象のサーバへ送信することを抑止し、新たなトラフィックをクラスタ内の残っているインスタンスに流すことで、インスタンスを取り除き、リクエストの消失をせずに正規の手順でシャットダウンすることができます。
OTDとの統合がアクティブであるためには、以下のドキュメントに記載されているように、ライフサイクル管理サービスをドメインに対して有効化する必要があります。
Oracle® Fusion Middleware  Using WebLogic Server Multitenant  12c (12.2.1) 
http://docs.oracle.com/middleware/1221/wls/WLSMT/configuring.htm#WLSMT475

The Big Picture - Tying It All Together

12.2.1のElasticityフレームワークは、オンプレミスの動的クラスタにおけるキャパシティ管理において多大な力と柔軟性を提供します。動的クラスタキャパシティ計画の一環として、Elasticityフレームワークを使って、動的クラスタの最小値、ベースライン、ピーク時のキャパシティ要件を考慮しつつ、そうした設定をクラスタの動的サーバ構成に組み込むことができます。WLDFポリシーとアクションを活用して、既知のキャパシティの増加・減少時、もしくはクラスタのパフォーマンスに基づいて、クラスタを拡張・縮小する自動化ポリシーを作成することができます。
スクリプト・インターセプタを使うと、仮想マシンプールと対話して仮想マシンをスケール中に追加・削除することができます。もしかすると共有VMをニーズに基づいてクラスタ間を異動することさえもできるでしょう。データソースインターセプタを活用し、スケールアップイベントによって影響を受けるデータベースのキャパシティ超過を防ぐこともできます。
さらに、そのように構成すると、Elasticityフレームワークはスケールイベント中にOTDと対話し、動的クラスタでのキャパシティの追加・削除時に新たなセッションや実行中のセッションを確実に安全に管理することができます。
今後のエントリでは、これらの機能の詳細に入っていきます。このエントリは、ユーザーの皆様が動的クラスタで弾力性を実装する上で役に立つ、利用可能な新機能の概要に過ぎません。来る数週間、数ヶ月で詳細の説明とこれらの強力な新機能を活用する例をご紹介する予定にしています。
しばらくの間、OTDと統合したポリシーベーススケールのデモをこちらからダウンロードすることができます。セットアップ、実行方法を記載は以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)
Policy Based Scaling Example
http://docs.oracle.com/middleware/1221/wls/ELAST/policy_based_scaling.htm#ELAST527
ご質問はコメントやメールで直接お寄せください。しばらくの間、WebLogic Server 12.2.1をダウンロードして探ってみてください。

Resources

Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1) 
Policy Based Scaling Example
http://docs.oracle.com/middleware/1221/wls/ELAST/policy_based_scaling.htm#ELAST527
サンプルコード
WebLogic Server 12.2.1 Documentation
http://docs.oracle.com/middleware/1221/wls/index.html
Oracle® Fusion Middleware Configuring Elasticity in Dynamic Clusters for Oracle WebLogic Server 12c (12.2.1)
http://docs.oracle.com/middleware/1221/wls/ELAST/index.html
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
Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1)
Dynamic Clusters
http://docs.oracle.com/middleware/1221/wls/CLUST/dynamic_clusters.htm#CLUST678
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
End-to-End Lifecycle Management
http://docs.oracle.com/middleware/1221/wls/WLSMT/concepts.htm#WLSMT725
Configuring WebLogic Server MT: The Big Picture
http://docs.oracle.com/middleware/1221/wls/WLSMT/configuring.htm#WLSMT475
Oracle Traffic Director 12.2.1 Documentation
http://docs.oracle.com/middleware/1221/otd/index.html
Java EL 3.0 Specification - JSR-000341 Expression Language 3.0
https://jcp.org/aboutJava/communityprocess/final/jsr341/index.html
- 0 件のコメント:
カテゴリ

[Java] A New JDK 9 Version String Scheme

原文はこちら。
https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version
JDK 9に対し予定されている変更で、それほど大きなものではないとはいえ重要なものが、JDKバージョン文字列体系のアップデートです。詳細はJEP 233に記載されています。
JEP 223: New Version-String Scheme
http://openjdk.java.net/jeps/223
新しいバージョン文字列体系により、メジャー、マイナー、CPU（Critical Patch Update）リリースをより簡単に識別することができるようになります。これは、JDKバージョン文字列の一部として各プロパティを分離した数値コンポーネントとして符号化することにより実現しよう、というものです。
Critical Patch Updates, Security Alerts and Third Party Bulletin
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
新しいMAJOR．MINOR．SECURITYという表現方法に従い、JDK 9のバージョン文字列はMAJORリリースコンポーネントを表す9で始まります。

例えば、もしJDK 9 GAリリース（バージョン文字列9）に続いてCPUが出た場合、CPUのバージョン文字列は9.0.1になります。
General Availability
http://openjdk.java.net/projects/jdk8/milestones#General_Availability
そのCPUに続いて、9.0.1に対して追加変更を伴うマイナーリリースが続く場合、新リリースのバージョン文字列は9.1.1になります。
"Massive" Minor Release Java 8u40 Packs a Punch
https://www.voxxed.com/blog/2015/03/massive-minor-java-release-8u40-packs-a-punch/ 
さらに続いて、マイナーリリースに続いて別のCPUが出る場合、その新しいCPUは9.1.2になります。以下、下表のようなリリースバージョンが想定されます。
 9  GA
 9.0.1  CPU：9 + 重要な変更
 9.1.1  マイナーリリース：9.0.1 + その他の変更
 9.1.2  CPU：9.1.1 + 重要な変更
 9.2.2  マイナーリリース：9.1.2 + その他の変更
 9.2.3  CPU：9.2.2 + 重要な変更
 9.2.4  CPU：9.2.3 + 重要な変更
 9.3.4  マイナーリリース：9.2.4 + その他の変更
バージョン文字列の個々のコンポーネントは0から始まり、リリースの種類に基づいて増加するので、ローカルにインストールしたものが3個目の文字列、つまりJDK 9バージョン文字列のコンポーネントである、SECURITYをチェックすることによって指定されたセキュリティベースラインに合致しているかどうかを簡単に確認することができます。
バージョン文字列体系が変わることによって、JDKバージョン文字列を処理するコードの調整が必要になる場合があります。例えば、JDK 9バージョン文字列の1個目の要素が、（1.9.0_ea-b19のように）常に1という値であることを想定しており、リリースを比較する場合に常に2個目の要素へスキップして読み飛ばしているような場合です。調整の詳細はJEPの文章に記載があります。
さらに、JEPの文章では、JDK 9バージョン文字列で符号化される可能性のある他の種類の情報、9.0.1+63のようなビルド番号について記載があります。

予定されている変更を試したい開発者の方は、JDK 9 Early Access Buildをjdk9.java.netからダウンロードして試すことができます。
JDK 9 Project - Building the next generation of the JDK platform
http://jdk9.java.net/
予定されているバージョン文字列体系の変更に対するフィードバックは、verona-devメーリングリストにお送りください。
- 0 件のコメント:
カテゴリ

[JavaScript, Java] Dynamic linker API for the Java platform (JEP 276)

原文はこちら。
https://blogs.oracle.com/sundararajan/entry/dynamic_linker_api_for_the

JEP 276は、Javaのための動的リンカAPIを定義しています。
JEP 276: Dynamic Linking of Language-Defined Object Models
http://openjdk.java.net/jeps/276 
このJEPでは、"プロパティを読み取り"、"プロパティの書き込み "、"callableオブジェクトの呼び出し"といった、invokedynamicのCallsitesと呼ばれる、オブジェクトへのハイレベルな操作をリンクするための機能」を提供します。こうしたプレーンなJavaオブジェクトに対するこうした操作の通常のセマンティクスのためのデフォルトリンカだけでなく、言語固有のリンカのインストールのためのファシリティも提供します。

Nashorn JavaScriptエンジンではすでに、プロパティのリンク、インデックスによるアクセス、スクリプトオブジェクトだけでなく、「外部」「ホスト」Javaオブジェクト（POJOs）への呼び出しのためにdynalinkライブラリを使っています。JEP-276を使用し、"jdk,dynalink"と命名されたJava 9モジュールのパブリック（JDK固有の）APIとしてdynalinkを公開します。


現在、"jdk9 sandbox"というOpenJDKリポジトリのJEP-276-branchという名前のブランチに、JEP-276のソースコードがあります。
OpenJDK / jdk9 / sandbox
http://hg.openjdk.java.net/jdk9/sandbox 
これは、最終的にjdk9リポジトリに取り込まれます。dynalink" APIで遊んでみたい方は、このフォレストをチェックアウトし、"JEP-276-branch"をビルドすることができます。
Java APIとともに使いたい場合には、最近jshellツールを使っています。
JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
http://openjdk.java.net/jeps/222 
以下はdynalink APIをJavaコードから使うためのjshell REPLのサンプルです。
import java.lang.invoke.*
// dynalink API lives in these packages
import jdk.dynalink.*
import jdk.dynalink.support.*

// dynamic 'operation' for a callsite. 'length' property
Operation op = new NamedOperation(StandardOperation.GET_PROPERTY, "length")

// method type of operation to be linked - length is 'int' value
MethodType mt = MethodType.methodType(int.class, Object.class)

// callsite descriptor
CallSiteDescriptor desc = new CallSiteDescriptor(MethodHandles.publicLookup(),
     op, mt)

// callsite
SimpleRelinkableCallSite cs = new SimpleRelinkableCallSite(desc)

// create a linker factory
DynamicLinkerFactory fac = new DynamicLinkerFactory()
// create dynalink linker
DynamicLinker linker = fac.createLinker()

// link the callsite
linker.link(cs)

// invoke it!
printf("array size %d\n", (int)cs.getTarget().invoke(new String[10]))

import java.util.ArrayList

// make a list and populate two elements
ArrayList<String> al = new ArrayList<>()
al.add("hello")
al.add("world")

// get 'length' of array list - which is nothing but size
printf("list size %d\n", (int)cs.getTarget().invoke(al))
上記のREPLでは、"array size 10" と "list size 2" をそれぞれ表示します。（異なる"this"オブジェクトが渡された場合に）lengthプロパティは自動的に配列の長さに再リンクされ、ArrayListのsize になることに注意してください。Javaオブジェクトのリンク（および再リンク）はdynalink実装に付属する"java beans linker"によって処理されます。
- 0 件のコメント:
カテゴリ ,

[Java, WLS, FMW] Using Diagnostic Context for Correlation

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/using_diagnostic_context_for_correlation
WebLogic診断フレームワーク（WLDF）とFusion Middleware Diagnostics Monitoring System（DMS）はログやJava Flight Recorder（JFR）といった診断成果物に関連する相関情報を提供します。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Introduction and Roadmap
WebLogic Diagnostics Framework (WLDF)
http://docs.oracle.com/middleware/1221/wls/WLDFC/intro.htm#WLDFC107
Oracle® Fusion Middleware Tuning Performance Guide 12c (12.2.1)
DMS Execution Context
http://docs.oracle.com/middleware/1221/core/ASPER/dms.htm#ASPER310
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プロセス内のスレッド間でリクエストとともに流れます。また、（OTDからDatabaseというような）他のOracle製品とのプロセス境界間も流れます。この相関情報は一意のIDの形で公開され、システムを流れる特定のリクエストを識別、相関付けするために利用できます。この情報はフローの順序の詳細も提供します。

相関IDは以下のようなものです。
  • 診断コンテキストID (DCID) と 実行コンテキストID (ECID)
    これはシステムを流れるリクエストを識別する一意の識別子です。利用しているのがWLDFかDMSかでIDの名前が異なりますが、実体は同じIDです。Oracle製品で幅広く使われている名前がECIDなので、ここでもECIDという名前を使います。
  • リレーションシップID (RID)
    このIDはフロー（やツリー）でリクエストが現在どこにいるかを示すために使うものです。このID自体はタスクツリーで各タスクの場所を示す順序セット順序付けされた数値の集合で、先頭の数字は通常はゼロです。先頭の数値の1は、全体のサブタスク・ツリー内でサブタスクの場所を追跡できないことを示します。
Oracle® Fusion Middlewareパフォーマンスのチューニング・ガイド 12c (12.1.3)
DMS実行リクエストおよびサブタスク
http://docs.oracle.com/cd/E57014_01/core/ASPER/dms.htm#ASPER311
Oracle® Fusion Middleware Tuning Performance Guide 12c (12.2.1)
DMS Execution Requests and Sub-Tasks
http://docs.oracle.com/middleware/1221/core/ASPER/dms.htm#ASPER311 
これらの相関IDはかなりの長期間にわたって存在します。12.2.1での新規事項は、WLDFがDMSのいくつかの機能をカバーするようになっています。
  1. DMSのRelationshipID (RID)機能をサポート
  2. HTTPに載って流入する相関情報のハンドリングが可能
  3. WebLogic HTTPクライアント利用時、相関をHTTPに載せて伝播可能
  4. 非継承Contextのコンセプト（今回は説明しませんが、このブログの別のエントリで取り上げられることでしょう）
このエントリでは、シンプルなシナリオを通じて、管理者がこの相関情報を使って迅速に特定のリクエスト・フローに関連する利用可能なデータを見つける方法をご紹介します。下図は基本的なシナリオを示しています。

図中のそれぞれの矢印は、コンテキスト伝播が発生し得る箇所を示していますが、この例では、伝播は青の矢印の箇所でのみ発生しています。この理由は、今回の例ではコンテキストを供給しないブラウザのクライアントを使っているためで、今回の場合はコンテキストはMySimpleServletが呼ばれた時点で生成されます。注意いただきたいのは、コンテキストを伝播できるクライアントが呼んだ場合、コンテキストはMySimpleServletを伝播することができる、ということです（例えばDMSが有効化されているHTTPクライアント、12.2.1以後のWebLogic HTTPクライアント、OTDなど）

今回のアプリケーションでは、DiagnosticContextHelper APIを使用して、ECID/RIDの値を各レベルで問い合わせ、サーブレットがこれらの値を返します。実際のアプリケーションではこんなことはしません。あくまでもサンプルの目的であり、サーブレットは値を表示することができます。
Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12c (12.2.1)
Class DiagnosticContextHelper
http://docs.oracle.com/middleware/1221/wls/WLAPI/weblogic/diagnostics/context/DiagnosticContextHelper.html 
EJBをハードコーディングし、サーブレットへのリクエストにクエリ文字列が含まれている場合に例外をスローするようにしています。アプリケーションはクエリ文字列を含むリクエストを検知した場合、警告をログに書き込みます。この警告ログメッセージは自動的にECID/RIDの値を含めるようになっています。アプリケーションは、ECID/RID取得のために特別なことをする必要はありません。
ここでつかっているアプリケーションと基本的な使い方を含めてここから入手できます。

まず、失敗しないURL (http://myhost:7003/MySimpleServlet/MySimpleServlet) でサーブレットを呼び出してみましょう。

上図から、すべてのアプリケーションコンポーネントが同じECID(f7cf87c6-9ef3-42c8-80fa-e6007c56c21f-0000022f)をレポートしていることがわかります。また、各コンポーネントが報告しているRIDは異なっており、各コンポーネントの関係は以下のようになっていることがわかります。

続いて、失敗するURL (http://myhost:7003/MySimpleServlet/MySimpleServlet?fail) でサーブレットを呼び出してみます。

EJBが失敗をレポートしていることがわかります。このサンプルアプリケーションでは、ECIDが障害が発生したフロー全体で"f7cf87c6-9ef3-42c8-80fa-e6007c56c21f-00000231"です。実際のアプリケーションでは、そうではないでしょう。管理者はおそらくほとんど最初に様々なサーバーログで報告されている警告を見るはずで、そこでこうした警告とともにECIDを見るはずです。この例ではECIDを知っているので、grepを使って、これらの警告がどういうものか、そうした警告にはECID/RIDがログで報告されていることを調べることができます。

障害があったことを確認すると、管理者は、関係しているすべてのサーバーからJFRデータをキャプチャします。実際のシナリオでは、管理者はログの警告や、自動通知やデータをキャプチャするように構成されたポリシーおよびアクション（以前はWatch（監視）およびNotification（通知）として知られていました）があるかもしれません。今回の例では、WLSTスクリプトには、JFRデータのキャプチャが含まれています。
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
ここで、みなさんがJFRとJava Mission Control（JMC）に精通されており、WebLogic Plugin for JMCをインストール済みであることを前提とします。



我々は障害に関連したECID（実際の場合にはこれはログの警告からになるでしょう）を持っているので、JMCでJFRのデータを読み出し、直接WebLogicタブグループのECIDタブに移動します。このタブには、初期状態で管理サーバのJFRからのフィルタリングされていないビューが表示されています。これにはこのJFR記録に存在するすべてのECIDが含まれています。

つづいて、"f7cf87c6-9ef3-42c8-80fa-e6007c56c21f-00000231"というECIDをコピーし、"Filter Column"にペーストします。

特定のECIDのみを表示して、当該ECIDに関連するJFR記録に存在するJFRイベントを選択することができます。
右クリックしてこれらの関連するイベントをJMCの「操作セット」機能に追加することができます。一度「操作セット」で実施すれば、JMCの他のビューも操作セットのみを表示するよう設定できます。詳しくは以下のドキュメントをご覧ください。
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
以下は、ejbServerとwebappServer JFRデータに対して同じフィルタ・ビューを示すスクリーンショットです。



今回の例では、意図的に発生させた失敗がアプリケーションコードにありました。結果として、ここで参照したJFRのデータからサンプル目的で全体のフローがわかりますが、この特定のケース自体での障害に対し、多くの洞察を与えるものではありません。障害で発生したJFRイベントは、何が失敗の原因になったのか、障害までの間に何が起こったのかを知るよい方法です。

詳細情報は以下のドキュメントをご覧ください。
- 0 件のコメント:
カテゴリ ,

[Java] Proposed Schedule Change for Java 9

原文はこちら。
https://blogs.oracle.com/java/entry/proposed_schedule_change_for_java
チーフJavaアーキテクトのMark ReinholdがJava 9のマイルストンを6ヶ月遅らせ、Feature Complete（FC）を2016年5月25日、General Availability（GA）を2017年3月23日に変更することを提案しました。

当初、Java 9のFeature Completeは2015年12月10日を予定していました。Mark ReinholdはOpenJDKのメーリングリストでマイルストンの繰り下げについて、以下のように説明しています。
"The JSR 376 EG has not yet published an Early Draft Review specification, the volume of interest and the high quality of the feedback received over the last two months suggests that there will be much more to come, and we want to ensure that the maintainers of the essential build tools and IDEs have adequate time to design and implement good support for modular development"
"JSR 376エキスパートグループはまだEarly Draft Review仕様を発行しておらず、この2ヶ月にわたって受け取った関心の高さと高い質のフィードバックをうけて、もっとフィードバックが届くと思われるので、基本的なビルドツールやIDEのメンテナーに、モジュラー開発のための良いサポートを設計し、実装するための十分な時間を確保したい"
Proposed schedule change for JDK 9
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html 
「繰り下げた結果生まれた時間は、新機能の追加ではなく、現在のJigsaw機能を安定化、洗練、ファインチューニングするために使うべきだ」、彼は警告しています。Jigsawは標準のモジュールシステムを導入し、そのシステムを使って、Java SE PlatformとJDKの両方をモジュール化します。

この提案に関する詳細は、OpenJDKメーリングリストをご覧ください。Java 9のモジュールシステムについては、MarkとAlam Batemanの最新のJava 9に関するプレゼンテーションをご覧ください。
Proposed schedule change for JDK 9
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html
Modularity in Java 9
https://blogs.oracle.com/java/entry/modularity_in_java_9
- 0 件のコメント:
カテゴリ
登録: 投稿 (Atom)