Quantcast
Channel: Oracle Blogs 日本語のまとめ
Viewing all 760 articles
Browse latest View live
↧

[WLS, FMW] Zero Downtime Patching Released!

November 19, 2015, 9:12 pm
$
0
0
原文はこちら。
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
↧
Search

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

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

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

November 22, 2015, 4:47 pm
$
0
0
原文はこちら。
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では見ることはできません。
↧

[Java] Proposed Schedule Change for Java 9

December 2, 2015, 5:49 pm
$
0
0
原文はこちら。
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
↧

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

December 3, 2015, 9:35 pm
$
0
0
原文はこちら。
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イベントは、何が失敗の原因になったのか、障害までの間に何が起こったのかを知るよい方法です。

詳細情報は以下のドキュメントをご覧ください。
↧
↧

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

December 3, 2015, 10:13 pm
$
0
0
原文はこちら。
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"によって処理されます。
↧

[Java] A New JDK 9 Version String Scheme

December 7, 2015, 5:51 am
$
0
0
原文はこちら。
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メーリングリストにお送りください。
↧

[WLS, FMW] Elasticity for Dynamic Clusters

December 8, 2015, 5:54 am
$
0
0
原文はこちら。
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
↧
Search

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

December 8, 2015, 6:29 am
$
0
0
原文はこちら。
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

↧
↧

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

December 8, 2015, 6:45 pm
$
0
0
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のドキュメントをご覧ください。

↧

[Java, WLS] Deploying Java EE 7 Applications to Partitions from Eclipse

December 9, 2015, 2:54 am
$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/deploying_java_ee_7_applications
新しいWebLogic Server 12.2.1 Multitenancy機能を使うと、それぞれが分離され、別々に管理可能なパーティションをドメインに作成することができます。開発の観点からすると、この分離は興味深い機会を開きます。例えば、それは彼らがURLや資源の相互アクセスの衝突を心配しなくても、同じアプリケーションで作業し、複数の開発者によって共有される単一のドメインを複数の開発者に共有し、同じアプリケーションに取り組むことができるにも関わらず、URLの衝突やリソースの相互アクセスを考える必要はありません。

パーティションのライフサイクルはその他のパーティションとは独立して管理することができるので、アプリケーションの立ち上げ・立ち下げのためにパーティションの起動・停止を他の共有ドメインユーザーに対して影響を与えずに実行できます。デプロイされたリソースやアプリケーションのすべてを含めてパーティションをドメインからエクスポート（取り外す）することも、全く別のドメインにインポート（取り付ける）し、正に同じパーティションを新しい場所にリストアすることができます。これにより、非常にわかりやすい方法で、様々な環境間で完全に実行可能なアプリケーションを共有し移動させることができます。
開発環境内でパーティションを利用するコンセプトの説明として、以下の動画をご覧ください。この動画ではJava EE 7のCargo Trackerアプリケーションを例に、様々なターゲットに対しEclipseからデプロイするという例です。
WebLogic Server 12.2.1 - Deploying Java EE 7 Applications to Partitions from Eclipse

Cargo Tracker - Applied domain-driven design blueprints for Java EE
http://cargotracker.java.net/
  • 最初の例では、CargoTrackerを既知のWebLogic Serverターゲットに、これもよく知られた「Run as Server」アプローチを使ってデプロイします。これはEclipseが構成済みサーバを起動し、アプリケーションをbase_domainにデプロイします。
  • 続く例は、"test"という同一ドメインに作成されたパーティションを使い、同一のアプリケーションコードベースをビルドし、mavenやweblogic-maven-pluginを使ってパーティションにデプロイしています。仮想ターゲットマッピングを使ってパーティションのアプリケーションにアクセスすると、想定通り動作する例を紹介しています。
  • デモの仕上げに、開発の変更を模倣するようCargoTrackerアプリケーションのIndexページを変更し、"uat"と呼ばれる別のパーティションにデプロイします。アクセスすると、ページの変更がなされていることがわかります。
  • この時点で、同じアプリケーションの3個のインスタンスすべては同一サーバ上で独立しており、同時にアクセスすることができます。基本的に単一ドメインで同一アプリケーションの複数インスタンスを独立してホストする方法を示しています。
↧

[WLS, Database] ONS Configuration in WLS

December 11, 2015, 7:23 am
$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/ons_configuration_in_wls
Oracle Real Application Clusters (RAC) やOracle Data Guard環境からノードやサービスを追加・削除する際に、高速アプリケーション通知（FAN）を使って、サービスやノードの通知イベントを提供します。
Oracle Notification SystemはFANのためのトランスポートとして利用されます。Oracle Notification Systemに関する詳細は以下のリンクからどうぞ。
Fast Application Notification (FAN)
Includes FANwatcher:
A utility to subscribe to ONS and view FAN events
Oracle White Paper | May, 2015
http://www.oracle.com/technetwork/database/options/clustering/overview/fastapplicationnotification12c-2538999.pdf
ONSの構成はWebLogic Server 10.3.6以後、Active GridLink（AGL）に対して利用可能です。最近のリリースでは、自動ONSが追加されました。それにより、もはや明示的なONSの構成が不要になり、設定しないことが推奨されていますが、いくつかのケースでは明示的にONSの設定を実施する必要があります。その理由の一つは、walletファイルとパスワードを指定する（これは自動ONSではできません）ことが必要だから、もう一つの理由は明示的にONSトポロジーを指定し、接続数に手を入れるためです。

ONS構成はWebLogic Server 12.2.1で機能強化されました。OnsNodeList値はシングルノードリストもしくはプロパティノードリスト（これはWebLogic Server 12.2.1で導入されました）のいずれかで設定する必要があります（両方ではありません）。WebLogic ServerのOnsNodeListに等号(=)が含まれている場合、シングルノードリストではなく、プロパティノードリストがあると想定されます。

シングルノードリスト

コロンで区切られたONSデーモンのリスンアドレスとポートのペアのカンマ区切りリスト

例：

instance1:6200,instance2:6200

プロパティノードリスト

この文字列は複数のレコードから構成されています。各レコードはキー=値のペアから構成され、改行文字（ '\ n'）文字で終了します。以下のキーを指定することができます。
  • nodes.<id>
    リモートONSサーバの一意のトポロジーを表すノードのリスト。 <id>はノードリストに対し一意の識別子を指定します。重複エントリは無視されます。任意のリストで構成されたノードリストには、同じクライアントに対し他のリストで構成されているノードや、重複する通知が送信・配信されるノードが含まれていてはいけません。リストのフォーマットは、ONSデーモンのリスニングアドレスとポートの組合せをコロンで区切ったもののカンマ区切りで並べたものです。
  • maxconnections.<id>
    ONSサーバで管理される最大同時接続数を指定します。<id>はパラメータが適用されるノードリストを指定します。デフォルト値は3です。
  • active.<id>
    trueの場合、リストはアクティブで、自動的に設定個数のONSサーバへの接続が確立されます。 falseの場合、リストは非アクティブで、アクティブリスト用の接続を確立できない場合にフェールオーバリストとしてのみ使われます。非アクティブリストは、一度に一つのアクティブなリストのためのフェールオーバとしての機能を果たすだけです。一度単一の接続がアクティブリストで再確立すると、フェールオーバリストは非アクティブに戻ります。リストがフェールオーバした後にクライアントが発行した通知のみがフェールオーバリストに送信されることに注意してください。 <id> はこのパラメータが適用されるノードリストを指定します。デフォルト値は trueです。
  • remotetimeout
    各リモートサーバへの接続に対するタイムアウト期間（単位はミリ秒）。リモートサーバがこのタイムアウト期間内に応答しなかった場合、接続を閉じます。デフォルト値は30秒です。
walletfile と walletpassword を文字列でサポートしていますが、WebLogic Serverはこれらの値に対し、別の構成要素であるOnsWalletFileとOnsWalletPasswordEncryptedを有していることにご注意ください。

この例は上記のシングルノードリストと同じ意味です。
nodes.1=instance1:6200,instance2:6200
データソースを構成して2個のクラスタに接続し、FANイベントを両クラスタから受け取る場合、例えばData GuardとともにRACを構成しているような場合、2個のONSノードグループが必要です。具体的には以下のようです。
nodes.1=rac1-scan:6200
maxconnections.1=4
nodes.2=rac2-scan::6200
maxconnections.2=4
URLには各クラスタに対し別々のADDRESS_LISTが必要で、SCAN名を拡張するために、ADDRESSごとにLOAD_BALANCE=ONを設定することをお忘れなく。

管理コンソールを使用してActive GridLinkデータソースを設定する場合、作成フローの中でプロパティノードリストを指定することはできません。その代わりに、データソース作成後、ONSタブでONSノード値を変更する必要があります。次の図は、2つのRACクラスタ用に2つのグループを使うプロパティノードリストの例です。

次の図は、ONSの統計情報監視ページを示しています。 2つのエントリがありますが、それぞれ各ホストとポートのペアです。

次の図は、rac2 ONSノード・グループをテストした後の監視ページの例です。

WLSTを使用して、ONSパラメータを作成することもできます。 ONS値の複数の行を埋め込まれた改行で区切る必要があります。以下はActive GridLinkデータソースを作成するための完全なサンプルです。
connect('weblogic','welcome1','t3://'+'localhost'+':7001')
edit()
startEdit()
cd('/')
dsName='aglds'
cmo.createJDBCSystemResource(dsName)
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName)
cmo.setName(dsName)
cmo.setDatasourceType(‘AGL’)
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCDataSourceParams/' + dsName )
set('JNDINames',jarray.array([String('jdbc/' + dsName )], String))
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCDriverParams/' + dsName
cmo.setUrl('jdbc:oracle:thin:@(DESCRIPTION=(CONNECT_TIMEOUT=4) (RETRY_COUNT=30)(RETRY_DELAY=3) (ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=rac1)(PORT=1521)))(ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=rac2)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=otrade)))')
cmo.setDriverName( 'oracle.jdbc.OracleDriver' )
cmo.setPassword('tiger')
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCConnectionPoolParams/' + dsName )
cmo.setTestTableName('SQL ISVALID')
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCDriverParams/' + dsName + '/Properties/' + dsName )
cmo.createProperty('user')
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCDriverParams/' + dsName + '/Properties/' + dsName + '/Properties/user')
cmo.setValue('scott')
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCDataSourceParams/' + dsName )
cmo.setGlobalTransactionsProtocol('None')
cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCOracleParams/' + dsName)
cmo.setFanEnabled(true)
cmo.setOnsNodeList('nodes.1=rac1:6200\nnodes.2=rac2:6200\nmaxconnections.1=4\n')
cd('/SystemResources/' + dsName )
set('Targets',jarray.array([ObjectName('com.bea:Name=' + 'myserver' + ',Type=Server')], ObjectName))
save()
activate()
自動的に設定されたONSを使うことができるならばそれが望ましいのですが、ONSを明示的に構成する必要がある場合、WebLogic Server 12.2.1には正確に要件を指定することができます。
↧

[Support, FMW] Fusion Middleware Lifetime Support Policy Update (December 2015)

December 15, 2015, 5:01 pm
$
0
0
原文はこちら。
https://blogs.oracle.com/proactivesupportEPM/entry/lsp_fmw_201512
Fusion Middlewareのライフタイム・サポート・ポリシーが先頃更新されました。
このドキュメントには、OracleのHyperionソフトウェアリリースに関連するライフタイムサポートの詳細が含まれており、Oracle Fusion Middleware 12c Certificationsに関わる情報が含まれています。
このドキュメントはOracle SupportのWebサイトからご覧いただけます。
ORACLE INFORMATION-DRIVEN SUPPORT
Oracle Lifetime Support Policy
Oracle Fusion Middleware 
http://www.oracle.com/us/support/library/lifetime-support-middleware-069163.pdf 
以下の製品群に関する新たな記載が含まれています。
  • Oracle Fusion Middleware 12.2.x
  • Oracle Business Intelligence Applications 11.1.1.10.1
  • Oracle GoldenGate Monitor 12.2.1
  • Oracle GoldenGate Veridata 12.2.x
以下製品に関する情報が更新されています。
  • Oracle Crystal Ball 11.1.2.x (サポート期間が延長されました)
Oracleのライフタイム・サポート・ステージやライフタイムサポートの特典を知りたい方、関連するOracleライフタイムサポートドキュメントにアクセスしたい方は、以下のWebページにアクセスしてください。
Oracle Lifetime Support Policies
http://www.oracle.com/us/support/lifetime-support/index.html
［参考］
↧
↧

[Java] Content Negotiation using 'q' Factors with JAX-RS 2/Java EE 7

December 15, 2015, 5:36 pm
$
0
0
原文はこちら。
https://blogs.oracle.com/theaquarium/entry/content_negotiation_using_q_factors
HTTPやコンテント・ネゴシエーションを考える場合、ほとんどの場合すぐにmime-typeのことを考えるでしょう。mime-typeは確かにクライアントとサーバ間でのHTTP通信で重要なものであってそれには同意しますが、HTTPにはもっときめ細かいコンテント・ネゴシエーション・メカニズムを持っており、それはrelative quality factor、略して'q' factorといいます。'q' factorはこれまでブラウザによるサポートが少なく、ほとんどの開発者があまり知られていませんが、q-factorを使うと、クライアントが複数のmime-typeをサポートし得る場合に、JPGよりもPNGを期待する、とすれば、期待するmime-typeに対するプリファレンスをクライアントが指定することができます。この'q' factorは基本的にmime-typeに紐付く0.0から1.0までの間の数で、より大きな数であればあるほど、より好ましいmime-typeであることを示します。同様に、サーバもまた、'qs' factor、もしくはquality of source factorを指定することによって、レスポンスとして送信するにはどのmime-typeが好ましいかを示すことができます。以下のリンクは、'q' factorについてベストと思われる説明です。
Content Negotiation Explained
http://www.apacheweek.com/features/negotiation 
この記事では、'q' factorが多少曖昧な性質であり、これまでのWebの世界では‘q’ factorベースのネゴシエーションをサポートするブラウザが少ないけれども、Apache httpdは、長い間強力に'q' factorをサポートしてきたという事実を指摘しています。
'q' factorベースのネゴシエーションはRESTで非常に価値があります。より堅牢なサービスAPIを書く手助けになる可能性があります。例えば、JSONもXMLもサポートするとして、クライアントが両方をサポートしている場合には、XMLよりJSONが好ましいと伝えることができるでしょう。同様に、柔軟に複数のコンテントタイプを処理できる、より強力なクライアントを作ることができます。パブリックREST APIを作成したり、全く予測できない様々なクライアントと関わったりする場合に、こうした機能が特に役立ちます。3rdパーティのサービスを使う場合、クライアント側でも同じことが言えます。ここでよいお知らせです。JAX-RS 2とJava EE 7では強力に'q' factorベースのコンテントネゴシエーションをサポートします。Sam SepassiがJAX-RS 2.0でのコンテント・ネゴシエーションに関するすばらしい記事を先頃Upしてくれました。
Content Negotiation in JAX-RS 2.0
https://dzone.com/articles/content-negotiation-in-jax-rs-20 
是非一読されて、この機能のよいユースケースがあれば利用を検討してください。
↧

[WLS, Java, FMW] 12.2.1 WebLogic JMS: Dynamic Scalability and High Availability Made Simple

December 19, 2015, 2:07 am
$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/12_2_1_weblogic_jms

Introduction

WebLogic Server 12.2.1はすばらしくシンプルな、簡単に利用できるJMS構成および管理モデルを特徴としています。このシンプルなモデルは、JMS構成が簡単で可搬性があるため、シームレスにクラスタとMulti-Tenant/クラウド環境の両方で動作します。12.1.2で追加されたJMSクラスタターゲット機能の初期バージョンにあった主な制限を、古い管理モデルでは利用できない機能拡張を付け加えることで基本的にクリアしています。
  • 全てのタイプのJMSサービスアーティファクトが動的クラスタ環境をフル活用でき、自動的にスケールアップするだけでなく、クラスタのサイズ変更に合わせて負荷をクラスタ間で均等に分散します。言い換えると、クラスタの成長または変化に応答して、JMSアーティファクトを各クラスタメンバに個別に構成、デプロイする必要はありません。
  • 高可用性構成（フェールオーバ、フェールバック、インプレース再起動）を簡単に構成でき、個別のターゲットを使うことで、以前は一部しかサポートしていなかった機能が使えるようになっています。
  • 12.2.1では、シンプルな構成モデルで、クラスタのシングルトン宛先を構成できるようになっています。
これらの機能はすべてのWebLogic Serverクラスタのタイプ、つまり、個々にWebLogic Serverを構成したものを組み合わせた旧来の静的なクラスタ、複数のインスタンスに伸長できる動的な1個のWebLogic Serverを組み合わせた動的クラスタ、そしてその両方を組み合わせたクラスタといったすべてのタイプに当てはまります。

Configuration Changes

このモデルを使うと、動的にスケールし、高可用性を持つJMSを一カ所（永続データを扱うすべてのJMSアーティファクトのためのカスタムストアもしくはメッセージング・ブリッジ）で簡単に構成、管理することができます。このモデルで導入されたこの新しい構成パラメータは総称して「高可用性」ポリシーとして知られています。これらは、管理コンソール（WebLogic管理コンソール、Fusion Middleware Control (FMWC)）だけでなく、WLSTスクリプトやJava Mbean APIを通じてユーザーに公開されています。ストア上にJMSを設定している場合、このストアを参照するJMSサービスのアーティファクトは、シンプルにこうした設定をストアから継承し、それに従った動作します。
Figure 1. Configuration Inheritance
最も重要な設定パラメータはdistribution-policy（分散ポリシー）とmigration-policy（移行ポリシー）です。これらはそれぞれ、関連するサービス・アーティファクトの動的な拡張性と可用性を制御します。
distribution-policyを構成済みのアーティファクトに”distributed”と設定した場合、デプロイ時に、システムが自動的にインスタンスを各クラスタメンバ上で作成します。"singleton"に設定すると、システムは、クラスタ全体で単一のインスタンスを作成します。

ホストのWebLogic Serverにちなんで分散インスタンスは一意に命名されています（構成した名称にはサーバ名が後ろにつく）。ここでホストのWebLogic Serverは、実行時の監視と位置の追跡のために最初に作成され、開始しています。このサーバは、それにちなんで命名されている分散インスタンスのホームまたは優先サーバーと呼ばれています。シングルトン・インスタンスは、サーバ名で装飾されず、そのかわりに単に「-01」が後ろについています。システムはインスタンスをホストするクラスタ内で管理対象サーバの1個を選択します。

distribution-policyは、migration-policyと呼ばれる新しい高可用性オプションと協調し、予期せぬサービス障害やサーバクラッシュ、あるいはサーバの計画停止に対してさえもインスタンスが停止しないことを保証します。このポリシーは使用可能なクラスタメンバーにインスタンスを自動的に移行することでこれを実現します。
migration-policy用に、3個の選択肢から1個選ぶことができます。

  • on-failure：インスタンスの移行は予期しないサービス障害やサーバクラッシュ時のみ
  • always：インスタンスの移行は計画的な管理されたサーバ停止をも含めて実施
  • off ：サービスレベルの移行を無効化（必要であれば）
Figure 2. Console screenshot: HA Configuration
migration-policyに加え、この新しいモデルでは、restart-in-place（インプレース再起動）と呼ばれる、ストアのための別の高可用性の概念を提供しています。これを有効にすると、システムはまず、クラスタ内の別のサーバーにフェールオーバーする前に、現在のサーバー上で失敗したストアインスタンスを再起動しようとします。このオプションを調整し、試行回数と各試行間の時間間隔を制限することができます。
この機能のおかげで、レイテンシや過負荷が原因でデータベースが停止したりネットワークやI/Oリクエストに対する応答がないといった一時的な不調時に、システムが不必要な移行をしなくてすみます。障害発生後（定期的に再接続しようとします）、すでに自動的に再起動しているため、ブリッジはrestart-in-place設定を無視します。
高可用性の強化は、障害発生時のサービス・アーティファクトのフェールオーバだけでなく、ホームサーバがクラッシュやシャットダウン後に再起動された際の分散インスタンスの自動的なフェールバックも提供する、ということにご注意ください。これらは以前のリリースではご利用いただけませんでした。この機能のおかげで、アプリケーションが可能ならいつでも高いレベルのサーバや設定の親和性を実現することができます。以前のリリースとは異なり、起動中、フェールオーバ中のいずれであっても、インスタンスがクラスタメンバ間で均等に分散されていることをシステムが保証しようとします。そのため、クラスタのあるサーバが突発的に過負荷になることを避けています。

下表は新しい分散、移行、restart-in-place設定をまとめたものです。
属性名説明オプションデフォルト
distribution-policyJMSサービスインスタンスの個数と名前を管理する[Distributed | Singleton]Distributed
migration-policy高可用性構成時に挙動を制御する[Off | On-Failure | Always]Off
restart-in-place正常なWebLogic Serverでの停止したストアインスタンスの自動再起動を有効にする[true | false ]true
seconds-between-restarts停止したサービスのrestart-in-placeの試行の時間間隔（秒）[1 … {Max Integer}]30
number-of-restart-attempts停止したサービスの移行前に再起動を試行する回数[-1,0 … {Max Long}]6
initial-boot-delay-secondsサーバでアーティファクトのインスタンスを起動するまでに待機する時間（秒）[-1,0 … {Max Long}]60
failback-delay-seconds優先サーバへアーティファクトがフェールバックするまでに待機する時間（秒）[-1,0 … {Max Long}]30
partial-cluster-stability-secondsクラスタが「定常状態」であると認識するまでの待機時間。その時間に達するまでは、いくつかのリソースだけクラスタ内で開始することができる。この設定により、クラスタにはゆっくり立ち上がったり、停止したりする時間が与えられる。[-1,0 … {Max Long}]240

Runtime Monitoring

前述の通り、クラスタを対象にした場合、システムは自動的に1個（シングルトン）もしくは複数（分散）のインスタンスを1個の構成済みアーティファクトから生成します。これらのインスタンスは、一意に命名された、適切なランタイムMBeanが背後にあります。適切に有効範囲を設定されたサーバ（マルチテナント環境の場合はパーティション）のランタイムMBeanツリーの下で、アクセスしたり監視したりすることができます。
Figure 3. Console screenshot: Runtime Monitoring
上図はクラスタに向けられたSAFエージェントのランタイムインスタンスがクラスタメンバーのサーバ名で一意になるよう装飾されているところを示すスクリーンショットです。

Validation and Legal Checks

ユーザーがこれらの新しいパラメータの無効な組み合わせを設定できないようにするための法的チェックと検証ルールがあります。次の2つの表は、これら2個の新しいポリシーがそれぞれリソースタイプとサービスの種類によってサポートする組み合わせを示したものです。

サービス・アーティファクト分散ポリシー移行ポリシー
OffAlwaysOn-Failure
永続ストアDistributed✓✓✓
Singleton✓✓
JMSサーバDistributed✓✓✓
Singleton✓✓
SAF エージェントDistributed✓✓✓
パス・サービスSingleton✓
メッセージング・ブリッジDistributed✓✓
Singleton✓

上記の表では、適法な組み合わせは、JMSサービスの種類に基づいて記載されています。たとえば、パス・サービス（順序単位や作業単位と呼ばれる、人気のあるWebLogic Serverの順序付け拡張を活用する、メッセージのルーティング情報を永続化、保持するメッセージングサービス）は、サービスやサーバの障害があってもクラスタ内で高可用性を保つ必要があるシングルトンサービスです。そのため、唯一の有効かつ適法な組み合わせは以下の通りです。
  • distribution-policy：singleton
  • migration-policy：always
アプリケーションで使用されているリソースのタイプに基づいて導出されるルールがあります。たとえば、同一の分散送り先をホストするJMSサーバや常にインポート済み送り先をホストするSAFエージェントのルールの場合、distribution-policyにsingletonを指定しても意味がありませんし、許可されていません。
リソース・タイプSingletonDistributed
JMSサーバ（分散送り先をホスト）✓
SAFエージェント（インポート済み送り先をホスト）✓
JMSサーバ（ シングルトン宛先をホスト）✓
パス・サービス✓
ブリッジ✓✓
こうした適法性チェックに違反する無効な組み合わせの場合、エラーになったり、ログメッセージに同様の内容を出力します。ある場合においては、デプロイメントサーバの起動に失敗することがあります。

Best Practices

改善された機能を十分に活用するには、最初に慎重にスケーラビリティと可用性の要件だけでなく、デプロイメント環境を確認して、あなたのJMSアプリケーションを設計してください。たとえば、アプリケーションをクラスタにデプロイするのか、マルチテナント環境にデプロイするのか、均一な分散送り先またはスタンドアロン（非分散）の宛先なのか、またはその両方を使用するかどうかを確認します。
上記の要件を確認してから、カスタム永続ストアを定義し、適切なJMSサービスの成果物と関連付けてください。この新しいHAパラメータが要件に応じて明示的に設定されていて（ガイダンスとして上記の表を使用してください）、JMSサービスのアーティファクトと、それに対応するストアの両方が同様に（同じクラスタ、マルチテナント環境の場合は同じリソースグループ、リソースグループ・テンプレートを）ターゲットにしていることを確認してください。
JMSの高可用性機構がWebLogic Serverのヘルス・モニタおよびシングルトン・サービスに依存していること、そしてクラスタ・リースと呼ばれる機構に依存していることを覚えておいてください。そのため、migration-policyがon-failureもしくはalwaysに設定されている場合、もしくはJMSアーティファクトのシングルトンインスタンスを作成したい場合は特に、有効なクラスタリーシング構成を設定する必要があります。WebLogic Serverは2個のリース方法（コンセンサス・リースとデータベース・リース）を用意していますが、ベストプラクティスとしてデータベース・リースを利用することを強く推奨します。
また、JMSアプリケーションは、多くの場合、直接トランザクションを使いますし、JMSの内部は暗黙的にトランザクションを使っているので、WebLogicのトランザクションシステムの可用性高めるように構成することを強く推奨します。WebLogicトランザクションの高可用性を担保するためには、デフォルト設定のままではなく、すべての管理対象サーバに明示的にリスニングアドレスとリスニングポート番号が構成されている必要があります。そうでなければ完全なトランザクションのHAサポートを得ることはできません。動的クラスタ構成の場合には、動的サーバテンプレート定義の一部として、これらの設定を構成することができます。
最後に、NodeManagerを使ってクラスタメンバのすべての管理対象サーバを起動することを推奨します。

WebLogic JMSに関する詳細情報は以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering JMS Resources for Oracle WebLogic Server 12c (12.2.1)
http://docs.oracle.com/middleware/1221/wls/JMSAD/title.htm
その他のOracle WebLogic Server 12.2.1の新しい改善点は、以下のリンクのWhat's Newの章をご覧ください。
Oracle® Fusion Middleware What's New in Oracle WebLogic Server 12.2.1 12c (12.2.1)
What's New in Oracle WebLogic Server 12.2.1
http://docs.oracle.com/middleware/1221/wls/NOTES/whatsnew.htm#NOTES107

Conclusion

WebLogic JMSのこうした新しい拡張機能を使用して、一般的にはWebLogic JMSの構成、管理に関わる時間やコストを大幅に削減しつつ、拡張性や高可用性を向上し、結果として投資利益を向上しながら使いやすくなるというメリットを享受することができます。
↧
Search

[WLS] Connection Leak Profiling for WLS 12.2.1 Datasource

December 19, 2015, 5:24 am
$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/connection_leak_profiling_for_wls
これはWebLogic Server 12.2.1におけるデータソース・プロファイリングの機能向上に関する3部作の一個目のエントリです。これらの機能向上はお客様ならびにOracle Supportからの要求でした。この機能はアプリケーションで問題を見つけ出す上で非常に役に立つと思います。

12.2.1までの接続リーク診断プロファイリングオプションでは、アイドルの予約済み接続がリークしていると判断するまでの時間として、接続プールの「非アクティブ接続タイムアウト」属性を正数（0では無効になります）に設定する必要があります。リークしていると判断した場合、接続が再利用され、予約スレッドに関する情報を診断ログに書き出します。長時間接続を保持するアプリケーションでは、後検出によりデバッグが複雑なアプリケーションエラーが発生する場合があります。この問題に対処し、使い勝手を向上させるために、接続リークプロファイリングの2つの機能拡張が使えるようになりました。
  1. 接続プールが最大容量に到達し、確保要求がPoolLimitSQLExceptionエラーになった場合に、すべての予約済み接続に対して接続リークプロファイルレコードを作成します。
  2. 接続がいつリークしていると判断するかを決定する際に利用するため、データソースディスクリプタにオプションのConnection Leak Timeout Seconds（接続リークタイムアウト）という属性を追加します。アイドル接続がタイムアウト値を上回った場合、リークプロファイルログメッセージを書き込み、接続をそのままにしておきます。
データソース接続プールのProfileType属性ビットマスクに既存の接続リークプロファイリングの値（0x000004） を設定しなければなりません。潜在的な接続リークを識別するためのInactiveConnectionTimeoutSecondsの代わりに、ProfileConnectionLeakTimeoutSeconds 属性を設定することでも代用できます。
以下は値を設定するWLSTスクリプトの例です。
# java weblogic.WLST prof.py
import sys, socket, os
hostname = socket.gethostname()
datasource='ds'
svr='myserver'
connect("weblogic","welcome1","t3://"+hostname+":7001")
# Edit the configuration to set the leak timeout
edit()
startEdit()
cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource +
'/JDBCConnectionPoolParams/' + datasource )
cmo.setProfileConnectionLeakTimeoutSeconds(120) # set the connection leak timeout
cmo.setProfileType(0x000004) # turn on profiling
save()
activate()
exit()
これは値設定後のコンソールページの様子です。プロファイルタイプとタイムアウト値がデータソースの診断タブに設定されていることに着目してください。

ProfileConnectionLeakTimeoutSeconds属性もしくはプールの容量を超えた場合のいずれかがトリガーになっているリーク用に、既存のリーク検出診断プロファイリングログレコード形式を使います。いずれの場合も、各予約接続に対して一回だけログレコードを生成します。その後接続をプールに解放し、再度予約して再びリークする場合、新たなレコードが生成されます。リソースリーク診断ログレコードの例を以下に示します。コンソールやデータソースプロファイル出力テキストファイルから出力を確認することができます。
####<mydatasource> <WEBLOGIC.JDBC.CONN.LEAK> <Thu Apr 09 14:00:22 EDT 2015> <java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:398)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:365)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:331)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:568)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:498)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:135)
at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiDataSource.java:522)
at weblogic.jdbc.common.internal.RmiDataSource.getConnectionInternal(RmiDataSource.java:615)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:566)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:559)
...
> <autoCommit=true,enabled=true,isXA=false,isJTS=false,vendorID=100,connUsed=false,doInit=false,'null',destroyed=false,poolname=mydatasource,appname=null,moduleName=null,
connectTime=960,dirtyIsolationLevel=false,initialIsolationLevel=2,infected=false,lastSuccessfulConnectionUse=1428602415037,secondsToTrustAnIdlePoolConnection=10,
currentUser=...,currentThread=Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads],lastUser=null,currentError=null,currentErrorTimestamp=null,JDBC4Runtime=true,supportStatementPoolable=true,needRestoreClientInfo=false,defaultClientInfo={},
supportIsValid=true> <[partition-id: 0] [partition-name: DOMAIN] >
接続のリークがあって、しかも有効な長時間実行する操作を有する可能性のあるアプリケーションでは、通常のアプリケーション実行に干渉せず、問題がある可能性のある接続のリストに目を通すことができます。
↧

[WLS] Closed JDBC Object Profiling for WLS 12.2.1 Datasource

December 19, 2015, 5:57 am
$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/closed_jdbc_object_profiling_for
クローズ済みのJDBCオブジェクトへのアクセスはよくあるアプリケーションエラーで、デバッグが難しいものです。そのような条件を診断するのに役立つ、新たなプロファイリングオプションがあります。これはclose()メソッドを呼び出してからConnection、Statement、ResultSetなどのJDBCオブジェクトにアクセスした場合に診断ログメッセージを生成します。

クローズ済みJDBCオブジェクトプロファイリングを有効化するには、データソースのProfileType属性のビットマスクは0x000400が設定されている必要があります。

以下は値を設定するためのWLSTスクリプトの例です。
# java weblogic.WLST prof.py
import sys, socket, os
hostname = socket.gethostname()
datasource='ds'
svr='myserver'
connect("weblogic","welcome1","t3://"+hostname+":7001")
# Edit the configuration to set the leak timeout
edit()
startEdit()
cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource +
'/JDBCConnectionPoolParams/' + datasource )
cmo.setProfileType(0x000400) # turn on profiling
save()
activate()
exit()
管理コンソールでは、診断タブの［クローズされた使用のプロファイル］のチェックボックスをONにする必要があります。

このクローズされた使用のログレコードには、2個のスタックトレースが含まれています。クローズ済みの利用ログレコードには次の2つのスタックトレースが含まれています。一つは最初にオブジェクトを閉じたスレッドのもの、もう一つは閉じたオブジェクトにアクセスしようとしたスレッドのものです。レコードの例を以下に示します。
####<mydatasource> <WEBLOGIC.JDBC.CLOSED_USAGE> <Thu Apr 09 15:19:04 EDT 2015> <java.lang.Throwable: Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]
at weblogic.jdbc.common.internal.ProfileClosedUsage.saveWhereClosed(ProfileClosedUsage.java:31)
at weblogic.jdbc.wrapper.PoolConnection.doClose(PoolConnection.java:242)
at weblogic.jdbc.wrapper.PoolConnection.close(PoolConnection.java:157)
...
> <java.lang.Throwable: Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]
at weblogic.jdbc.common.internal.ProfileClosedUsage.addClosedUsageProfilingRecord(ProfileClosedUsage.java:38)
at weblogic.jdbc.wrapper.PoolConnection.checkConnection(PoolConnection.java:83)
at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:106)
at weblogic.jdbc.wrapper.Connection.createStatement(Connection.java:581)
...
> <[partition-id: 0] [partition-name: DOMAIN] >
このプロファイルオプションを有効にすると、オブジェクトがすでにクローズされていることを示す例外に、どこでクローズが発行されたのかを示すネストされたSQLExceptionが含まれています。以下がその例です。
java.sql.SQLException: Connection has already been closed.
at weblogic.jdbc.wrapper.PoolConnection.checkConnection(PoolConnection.java:82)
at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:107)
at weblogic.jdbc.wrapper.Connection.createStatement(Connection.java:582)
at Application.doit(Application.java:156)
...
Caused by: java.sql.SQLException: Where closed: Thread[[ACTIVE] ExecuteThread: ...
at weblogic.jdbc.common.internal.ProfileClosedUsage.saveWhereClosed(ProfileClosedUsage.java:32)
at weblogic.jdbc.wrapper.PoolConnection.doClose(PoolConnection.java:239)
at weblogic.jdbc.wrapper.PoolConnection.close(PoolConnection.java:154)
at Application.doit(Application.java:154)
... 
接続がすでにクローズされたことを示すエラーが出てどこでそれが起こったのかわからないときに、この機能は非常に有用です。スタックトレースを出力するためのオーバーヘッドがあるため、通常は本番環境でこのオプションを有効にしたままにしないでおきましょう（そのためデフォルトで有効にはなっていません）。とはいえ、問題を解決が必要であれば、このオーバーヘッドには価値があります。
↧
↧

[WLS] Local Transaction Leak Profiling for WLS 12.2.1 Datasource

December 19, 2015, 6:32 am
$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/local_transaction_leak_profiling_for
これは、WebLogic Server 12.2.1のプロファイリングの機能強化に関する一連のエントリの三個目です。
これは、アプリケーションがローカルトランザクションを開いたままにして接続プールに戻された場合によくあるアプリケーションエラーで、診断が困難なものです。このエラーは、XAException/XAER_PROTO、またはデータベースのアップデートの意図せぬローカルトランザクションのコミットやロールバックとして現れることがあります。接続がリリースされた場合のローカルトランザクションの内部のコミット、ロールバックに対する現在の回避策は、アプリケーションに現れるエラーをマスクするだけでしかなく、まだデータの矛盾の可能性が残っています。
Oracle JDBC thin driverはローカルトランザクションの接続の状態を取得する独自の方法をサポートしていますが、接続プールにリリースされた時に接続でローカルトランザクションを検知した場合にログエントリを追加する、新しいプロファイリングオプションが追加されています。ログレコードにはコールスタックと接続をリリースしたスレッドに関する詳細情報が含まれています。

ローカルトランザクションのリークプロファイリングを有効化するためには、データソース接続プールのProfileType 属性のビットマスクに0x000200 という値を含める必要があります。

以下は値を設定するためのWLSTスクリプトの例です。
# java weblogic.WLST prof.py
import sys, socket, os
hostname = socket.gethostname()
datasource='ds'
svr='myserver'
connect("weblogic","welcome1","t3://"+hostname+":7001")
# Edit the configuration to set the leak timeout
edit()
startEdit()
cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource +
'/JDBCConnectionPoolParams/' + datasource )
cmo.setProfileType(0x000200) # turn on  transaction leak profiling
save()
activate()
exit()
プロファイルタイプを設定する場合、複数のプロファイルオプションを一緒に組み合わせることができます。

管理コンソールでは診断タブで、接続ローカル・トランザクション・リークのプロファイル（Profile Connection Local Transaction Leak）のチェックボックスを使って有効化できます。

ローカルトランザクション・リークプロファイルのレコードには2個のスタックトレースが含まれています。一つは予約しているスレッドからのもの、もう一つは接続がクローズされたときのスレッドによるものです。ログレコードの例を以下に示します。
####<mydatasource> <WEBLOGIC.JDBC.CONN.LOCALTX_LEAK> <Thu Apr 09 15:30:11 EDT 2015> <java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:398)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:365)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:331)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:568)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:498)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:135)
at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiDataSource.java:522)
at weblogic.jdbc.common.internal.RmiDataSource.getConnectionInternal(RmiDataSource.java:615)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:566)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:559)
...
> <java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionPool.release(ConnectionPool.java:1064)
at weblogic.jdbc.common.internal.ConnectionPoolManager.release(ConnectionPoolManager.java:189)
at weblogic.jdbc.wrapper.PoolConnection.doClose(PoolConnection.java:249)
at weblogic.jdbc.wrapper.PoolConnection.close(PoolConnection.java:157)
...
> <[partition-id: 0] [partition-name: DOMAIN] >
レコードを見ると、アプリケーションのどこでクローズが実施されたのかを確認できますので、クローズする前に適切にトランザクションを完了させてください。
↧

[WLS] ZDT Patching; A Simple Case – Rolling Restart

December 19, 2015, 7:15 am
$
0
0
原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/zdt_patching_a_simple_case
ZDT（Zero Down Time）パッチ適用を理解するために、その最も単純な形であるローリング・リスタートを見てみましょう。この単純なユースケースは、Javaのバージョン、Oracleのパッチ、アプリケーションの更新といった類のロールアウトの基礎です。エンドユーザに対するサービスを停止させず、セッションデータを失わない状態を保証しながら、ローリング・リスタートを実行するには、ドメインやクラスタ内のすべての管理対象サーバの協調とコントロールされたシャットダウンが必要です。

管理者はローリング・リスタートを以下のWLSTコマンドを発行して開始することができます。
rollingRestart("Cluster1")
今回の場合、ローリング・リスタートは、「Cluster1」という名前のクラスタ内のすべての管理対象のサーバーに影響します。これはターゲットと呼ばれています。ターゲットは、単一のクラスタ、クラスタのリスト、またはドメイン名を取り得ます。

コマンドを入力すると、WebLogic管理サーバーがターゲットのトポロジーを分析し、動的にワークフローを作成します（ロールアウトとも呼ばれます）。これは、管理対象サーバ上のすべてのセッションが他の管理対象サーバで利用できるようにしながら、正常にシャットダウンし、クラスタ内の各管理対象サーバを再起動するためにとられるべき各ステップからなります。このワークフローは、次のノードに移動する前に、管理対象サーバ上で実行中のすべてのアプリケーションがエンドユーザからのリクエストを受け入れる準備が完全に整ったことも保証します。完全に一度クラスタ内のすべての管理対象サーバが再起動された場合には、ローリング・リスタートが完了しています。

以下は非常にシンプルなトポロジーでのこのプロセスを説明する図ですが、この図を見ると、ノードがオフライン（赤くなっている）になって、そのノードへ届くはずだったエンドユーザのリクエストが別のアクティブなノードへ再ルーティングされていることがわかります。オフラインノードのサーバが再起動され、アプリケーションが再度リクエストを受け入れる準備が整えば、このノードがアクティブなノードのプールに追加され、ローリング・リスタートは別のノードに移ります。
Animated image illustrating a rolling restart
クラスタでのローリング・リスタート
ローリング・リスタートの機能はお客様からのフィードバックをもとに導入されました。管理対象サーバで動作するアプリケーションのメモリ使用量をリフレッシュすることを目的として、先回りして管理対象サーバを再起動する、というポリシーをお持ちのお客様がいらっしゃいます。この機能を使用して、エンドユーザーに影響を与えずに、手間と時間のかかるプロセスを非常に簡素化しています。

Zero Downtime Patchingを使ったローリング・リスタートに関する詳細情報は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
Initiating a Rolling Restart of Servers
http://docs.oracle.com/middleware/1221/wls/WLZDT/configuring_patching.htm#WLZDT170
↧

[misc] Upper Stackを使う際に役立つかもしれないJDeveloperの設定やTips

December 21, 2015, 8:01 pm
$
0
0
この記事は JPOUG Advent Calendar 2015の22日目のエントリです。昨日はYousuke Yadaさんのエントリでした。
任意の待機イベントを擬似的に発生させる方法
http://blog.livedoor.jp/y_db_y/archives/46343044.html
今回は、備忘録的なものですが、Upper StackであるSOA Suite、BPM Suiteの開発をする上で設定しておいたほうがいいJDeveloperの設定をご紹介します。
その前に、11gまでは、SOA/BPMの開発では素のJDevelooerをインストールし、Upper Stackに必要なExtensionをインポートする構成でしたが、12c以後では、SOA用のJDeveloper、BPM用のJDeveloperがそれぞれQuick Start Installerとして用意されたものを使うように変わっています。
BPMのQuick Start Installerに含まれるJDeveloperを使うと、SOAの開発も可能です。包含関係は以下のような感じです。なお、SOA Quick Startを使うと、OEP、OSBの開発もできます（逆に11gまではOracle Enterprise Pack Eclipseを使って両者の開発をしていましたが、12cからはできなくなっています）。

JDeveloperで利用するヒープサイズを変更する

デフォルトでは最小128MB、最大640MBですが、もっとメモリを割り当てたい、という場合には以下のように設定します。

［場所］
<JDEV_HOME>/jdeveloper/ide/bin/ide.conf
［設定］
AddVMOption -Xms、-Xmx部分を変更。以下は例。
AddVMOption  -Xms128M
AddVMOption  -Xmx2048M

JDeveloperで利用するPermanent領域のサイズを変更する（JDK 7まで）

ADF、JSFでUIを作成しているときに、「メモリが不足しています…」という忌まわしいメッセージが出ることがあります。これはADFやJSFでの開発をする方はご存知かもしれませんが、JDeveloperでページのイメージを生成する際にPermanent領域を使っているからです。Permanent領域を増やすには、以下の設定を施します。BPMのヒューマンタスク用フォームを作成する場合、2GBほどを割り当ててください。

［場所］
<JDEV_HOME>/jdeveloper/jdev/bin/jdev.conf
［設定］
AddVMOptionHotspot部分を変更。以下は例。
AddVMOptionHotspot  -XX:MaxPermSize=2048M

保存時にプロジェクトを生成しないようにする

12cR1以後、「プロジェクトを保存後に作成」という保存アクションがデフォルトで有効になっています。
これは12cR2でも同様ですので、保存後動作が固まる（ようにみえる）のを避けるには、プリファレンス＞コード・エディタ＞保存アクションで、設定を削除する必要があります。

JDeveloperのユーザーディレクトリを変更する

JDeveloperは、デフォルトで
%APPDATA%\JDeveloper (Windows)
$HOME/.jdeveloper (Linux, Mac OS X)
をユーザーディレクトリとして利用しますが、複数のバージョンが混在する場合であれば、ユーザーディレクトリをわける必要があります。
ドキュメントにあるように、環境変数JDEV_USER_DIRを作成し、<JDEV_HOME>/jdeveloper/jdev/bin/jdev.bootに
ide.user.dir.var = JDEV_USER_HOME,JDEV_USER_DIR
と指定します。複数の環境があるならば、この環境変数をShellもしくはcmd/batファイルで定義し、そのファイルからJDeveloperを起動する、ようにしておくと、異なるバージョン、リリースのJDeveloperが相互干渉せずにそれぞれ別のユーザーディレクトリを使うことができます。
例えば、こんな感じです（以下はWindowsの例）
@echo off
set PATH=C:\Oracle\MW\soa1213\soa\plugins\jdeveloper\integration\adapters\lib;%PATH%;
set JDEV_USER_DIR=C:\JDeveloper\soa1213
C:\oracle\MW\soa1213\jdeveloper\jdeveloper.exe

Javaクラスをさくっと発見したい

Upper Stackとはいえ、APIを使ったカスタム開発が必要になることがあります。例えばOSBのJava Calloutで呼び出したいクラスを作成したいんだけど、あのクラスはどのパッケージに存在するんだったかな、という場合です。ほとんどの場合、IDEがよろしくやってくれますが、[ctrl]と[-]を押すと、検索窓が出ます。例えば、以下ではMapMessageと入れてみました。javax.jmsに含まれるクラスだということがわかります。

そして、ここでお目当てのクラスをクリックすると、このクラスが持つメンバを確認することができます。

JDeveloperのロケールを英語に強制する

JDeveloperは、日本語、英語のみ対応していますが、JDeveloperで発生した例外再現手順をサポートチームへ伝える場合、英語版で説明したほうが解決が速い場合があります。英語環境にするには、以下のように設定します。

［場所］
<JDEV_HOME>/jdeveloper/jdev/bin/jdev.conf
［設定］ 
AddVMOption -Duser.language=en
AddVMOption -Duser.country=US
色々JDeveloperには隠れた機能がありますので、ご興味のある方はぜひ探してみてください。明日はTakahiro Kitayamaさんです。よい休日をお過ごしください。

↧
Viewing all 760 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>