JMX API の拡張 |
ドキュメントの目次 |
Java Management Extensions (JMX) テクノロジが、Java 2 Platform, Standard Edition (J2SE) 5.0 の Java プラットフォームに追加されました。今回、Java Platform, Standard Edition (Java SE) 6 の JMX API における、もっとも大きな拡張内容を次に示します。
- JMX API で総称が完全にサポートされるようになりました。
- MXBean が追加されました。MXBean は、関連する値を一緒にバンドルできる便利な方法を提供する MBean です。これにより、特別にバンドルを処理するように構成されたクライアントを用意する必要がなくなりました。J2SE 5.0 のプラットフォームには、すでに MXBean の定義済みセットが用意されていますが、Java SE 6 で、ユーザー定義の MXBean をプログラムできるように API が導入されました。詳細については、『JMX テクノロジのチュートリアル』の「MXBean の導入」を参照してください。
- MXBean の記述子が追加されました。記述子によって、MBean に関する追加情報を管理クライアントに提供できます。詳細については、『JMX テクノロジのチュートリアル』の「MBean 記述子」を参照してください。
- 新しいクラス、javax.management.JMX が、定数および静的メソッドを格納するために追加されました。
- JMX Monitor API で複合型がサポートされるように改善されました。以前は、単純型の属性のみの監視でしたが、この場合、監視すべき値が多くの複合型に埋もれてしまいます。監視の詳細については、『JMX Specification, version 1.4』を参照してください。
- ObjectName で、
key=*
のワイルドカードがサポートされるようになりました。以前は、名前にkey1=value1
を持つ MBean と一致させるために"domain:key1=value1,*"
が使用されましたが、名前にkey1
を持つ MBean と一致させるために"domain:key1=*"
を使うことはできませんでした。今回のリリースでは、それが可能となりました。次のリストには、Java SE 6 プラットフォームにおける JMX API の変更点がすべて記載されています。関連事項がある場合は、それに対応したバグレポートや RFE (機能拡張要求) へのリンクを用意しています。
- 総称化
- MXBean
- 記述子
- 新しいクラス javax.management.JMX
- NotificationBroadcaster と NotificationBroadcasterSupport
- ObjectName
- 標準 MBean
- 動的な MBean
- Model MBean
- Open MBean
- 監視サービス
- タイマーサービス
- MLet サービス
- 関係サービス
- クエリー
- MBeanServerInvocationHandler
- 直列化形式
- アクセス権のチェック
- MBean RuntimeException 処理
- JMX Remote API の拡張
総称化
J2EE 1.4 と J2SE 5.0 の両方で バージョン 1.2 の JMX API が統合されたことによる制約は、J2SE 5.0 で総称化できなかったことでした。今回のリリースでは、この点が修正されました (4847959)。総称化の多くは総称化されたコレクション API (
java.util.List
など) のアプリケーションで構成されています。したがって、たとえば、MBeanServer.queryNames
が単にSet
返していた状況でも、今回の変更により、Set<ObjectName>
が返されるようになりました。また、javax.management.openmbean.OpenType
クラスとそのサブクラスも総称化されたため、型の制約を表現できるようになりました。OpenMBeanAttributeInfoSupport
とOpenMBeanParameterInfoSupport
は、自身のコンストラクタ内で型の制約を取得して、デフォルト値や有効な値を正しい型にする要求を満たします。StandardMBean
コンストラクタ も同様に型の制約を取得するため、リソースパラメータでインタフェースパラメータによって指定されたインタフェースが確実に実装されます。次のクラスとメソッドが更新されました。
- MBeanServer[Connection].queryMBeans は Set<ObjectInstance> を返します
- MBeanServer[Connection].queryNames は Set<ObjectName> を返します
- AttributeChangeNotificationFilter.getEnabledAttributes は Vector<String> を返します
- AttributeList は ArrayList<Object> を拡張します
- MBeanServerFactory.findMBeanServer は ArrayList<MBeanServer> を返します
- NotificationFilterSupport.getEnabledTypes は Vector<String> を返します
- ObjectName クラスのコンストラクタと getInstance メソッドは、従来、Hashtable を保有しましたが、今回から Hashtable<String,String> に変更されます
- ObjectName.getKeyPropertyList は Hashtable<String,String> を返します
- openmbean.CompositeType.keySet は Set<String> を返します
- TabularType.getIndexNames は List<String> を返します
- Relation.getReferencedMBeans は Map<ObjectName,ArrayList<String>> を返します
- RelationServiceMBean の場合:
- findAssociatedMBeans は Map<ObjectName,ArrayList<String>> を返します
- findRelationsOfType は List<String> を返します
- getRole は List<ObjectName> を返します
- findReferencingRelations は Map<String,ArrayList<String>> を返します
- getAllRelationIds は List<String> を返します
- getAllRelationTypeNames は List<String> を返します
- getRoleInfos は List<RoleInfo> を返します
- getReferencedMBeans は Map<ObjectName,ArrayList<String>> を返します
- sendRelationRemovalNotification は List<ObjectName> を保有します
- updateRoleMap は List<ObjectName> を保有します
- sendRoleUpdateNotification は List<ObjectName> を保有します
- sendRoleUpdateNotification は List<ArrayList> を保有します
- RelationType.getRoleInfos は List<RoleInfo> を返します
- MBeanServerNotificationFilter.get{Enabled|Disabled}ObjectNames は Vector<ObjectName> を返します
- RelationNotification の場合:
- constructor arg theUnregMBeanList は List<ObjectName> に変更されます
- constructor args the{New|Old}RoleValue は List<ObjectName> に変更されます
- getMBeansToUnregister は List<ObjectName> を返します
- get{Old|New}RoleValue は List<ObjectName> を返します
- RelationServiceMBean に指定された RelationService メソッドもRelationServiceMBean の変更点を継承します
- Relation に指定された RelationSupport メソッドも Relation の変更点を継承します
- RelationTypeSupport.getRoleInfos は List<RoleInfo> を返します
- Role コンストラクタと getRoleValue は List<ObjectName> を使用します
- RoleList は ArrayList<Object> を拡張します
- RoleUnresolved は List<ObjectName> を使用します
- RoleUnresolvedList は ArrayList<Object> を拡張します
- Timer[MBean].get[All]NotificationIDs は Vector<Integer> を返します
MLetMBean と MLet's getMBeansFromURL メソッドは、戻り値の Set 要素が ObjectInstance または Throwable のどちらかになる可能性があるため、総称を使用することはできません。AttributeList、RoleList、RoleUnresolvedList は、より自然な表現である ArrayList<Attribute> などではなく、ArrayList<Object> を拡張します。ArrayList<Attribute> などは、既存の add メソッドと set メソッドがそれぞれ boolean や Object ではなく void を返すため、不整合が発生する可能性があるためです。
新しいメソッド AttributeList.asList()、RoleList.asList()、RoleUnresolvedList.asList() は、正しい型のパラメータを持つ基本オブジェクトの
List
ビューを生成します。新しいコンストラクタ AttributeList(List<Attribute>) は、逆の方向に転換します (RoleList と RoleUnresolvedList にはすでにこのようなコンストラクタがあります)。総称化の原理の詳細には、API 生成時に作成された選択肢が記載されています。
MXBean
従来、複合型のポータブルモデリングには Open MBean を使用して実行する必要がありましたが、これは扱いにくいものです。そのため、J2SE 5 には複合型をより簡単にモデリングできるように MXBean が追加されました。今回、このリリースから、この MXBean が一般化されました (6175517)。MXBean は、Java インタフェースの型と管理インタフェースの型の間で非一致マッピングを提供する標準 MBean の特別な種類です。標準 MBean と同じ方法で、MXBean には getX メソッドや setX メソッドで定義される属性が含まれます。他のメソッドは操作内容を示します。ただし、MXBean を使用すると、実際に MBean サーバーに登録された MBean では、その属性、操作パラメータ、および戻り値に対応するまったく同じ型が含まれないことになります。その代わり、MXBean インタフェースで発生するそれぞれの型は、
javax.management.openmbean
に定義されている固定セットで構築された型に変換されます。MBean サーバーに実際に登録されている MBean は、これらの変換された型を参照する Open MBean です。MBean はアクセスされると、元の MXBean インタフェース型と変換後の Open MBean 型の間で値を変換します。この方法を使用することで、クライアントは、MXBean インタフェースで参照される可能性のあるモデル固有の型を識別する必要なく MXBean にアクセスできます。クライアントは標準の Open MBean 型を識別するだけですみます。
MXBean の完全な仕様は、注釈
@MXBean
のドキュメントに記述されています。MXBean の導入により、次のクラスとインタフェースが追加または影響されました。
- javax.management.StandardMBean: 標準 MBean と同様に MXBean で使用可能。
- javax.management.MBeanServerInvocationHandler: 標準 MBean プロキシと同様に MXBean プロキシで使用可能。
- javax.management.JMX:4 つの新メソッドを持つ新しいクラス。
- javax.management.MXBean: 新しい注釈。
- javax.management.openmbean.CompositeDataInvocationHandler : 2 つの新メソッドを持つ新しいクラス。
- javax.management.openmbean.CompositeDataView:1 つの新メソッドを持つ新しいインタフェース。
- クラス
StandardMBean
が MXBean の作成に使用可能。また、このクラスはMBeanRegistration
を実装するようになりました。これにより、MXBean が登録された名前を追跡して、内部 MXBean の参照内容を正確に処理できます。記述子
記述子を使用して、MBean の追加のメタデータを提供できます。従来は、Model MBean のみが記述子をサポートしていました。今回のリリースでは、すべての MBean 型で記述子がサポートされるようになりました (6204469)。また、このリリースでは、すべての MBean 型のメタデータの汎用性に加え、さまざまな MBean 間にある不要な差異をなくしています。特に、Open MBean と Model MBean の両方に属する MBean を持つことができるようになります。
クラス MBean*Info (MBeanInfo, MBeanAttributeInfo など) のほとんどのコンストラクタの場合、同じパラメータに加えて追加の Descriptor パラメータを持つ並列のコンストラクタが追加されました。また、OpenMBean*InfoSupport も同様です。
Open MBean は、
OpenMBeanParameterInfo
およびOpenMBeanAttributeInfo
のメソッドgetDefaultValue()
、getLegalValues()
、getMaxValue()
、getMinValue()
から、デフォルトに関する情報と有効な値を返します。今回、この情報が対応する記述子にも含まれるようになりました。また、他の MBean 型も自身の記述子の情報を返すことができます。javax.management.DescriptorRead と呼ばれる DescriptorAccess の親インタフェースが追加されました。これには、getDescriptor メソッドが含まれますが、setDescriptor メソッドは含まれません。MBean*Info クラスは DescriptorRead を実装します。
次に、javax.management.ImmutableDescriptor と呼ばれる記述子インタフェースの不変実装も追加されました。これを使用すると、不変のメタデータを持つすべての MBean (Model MBean 以外) のプロパティーが保存されます。
新しい型の記述子項目 (フィールド) が
Descriptor
仕様に記述されました (6254721)。これらの項目の一部は、実装 (仕様ではイタリック体) によって識別されますが、他に関しては識別されずに残ります。あらかじめ定義されたフィールド名は、新しいJMX
クラスに対応する文字列定数を持っています (6282502)。新しい注釈
DescriptorKey
を使用すると、標準 MBean (または MXBean) インタフェースの注釈から標準 MBean (または MXBean) の記述子に情報を追加できます (6221321)。これによって、ツールが既存の管理モデルから標準 MBeans を生成し、そのモデルからの情報を別のファイルではなく生成された MBean インタフェースに持たせることができます。メソッド
Descriptor.getFieldValues(String...)
とコンストラクタDescriptorSupport(String...)
は、従来はString[]
パラメータを持っていました。varargs の構文により、これらが使いやすくなりました。他にも、次のように記述子に関連した変更点が多くあります。
6255956: 記述子は
equals
メソッドを定義して、配列値の比較方法を指定します。Descriptor
のインタフェースは、equals
メソッドと、それに実装する 2 つの固定実装を指定します。これは、記述子を平等に考慮するために、MBeanInfo
などの比較が継続して行われることを意味します。また、異なるDescriptor
の実装が混在できるように、hashCode()
メソッドも指定されて、実装されます。6267824:
Descriptor.getFieldValues(null)
を呼び出すと、戻り値の配列がソートされた順番の方法が明確になります。従来は、戻り値の順番の方法を指定しませんでした。6273765: 空の記述子にある Descriptor.getFieldValues (空の配列ではない) は特に動作しません。このメソッドの戻り値の配列には、パラメータの数だけ要素があります。各要素は、対応するパラメータに関連付けられた値です。値が存在しない場合、null が使用されます。
従来、見落としや編集上のエラーがあった場合、このメソッドの @returns 節は、If the descriptor is empty, you will get an empty array. というメッセージを表示していました。まず間違いなく、このメッセージの意味するところは、名前のリストが空の場合、空の配列を取得する、ということです。ここでは、指定されているとおり、1 点の有害な特殊ケースがありました。リストの名前の一部、またはすべてが記述子から消えている場合、戻り値の配列にある対応する要素が null になるということです。ただし、記述子が空の場合、配列には要素が何も入りません。
この特殊なケースは、既存の Model MBean の記述子を使用する分には、空の記述子が使用されるどの場所でも有効にならないため、発生しませんでした(すべての記述子は、最低でも「名前」と「記述子の型」のエントリを持っていることが必須)。ただし、記述子の使用法がより一般化されたため、現在この事例は当てはまりません。そのため、従来指定されていた動作内容で、バグが発生することはまずありませんでした。
6273613:
Descriptor.setField
とDescriptor.setFields
のラップされた例外を指定します。従来、これらのメソッドは、RuntimeOperationsException
をスローするように宣言されていましたが、仕様でラップされた例外がどのようなものかは指定しませんでした。6289244: MBeanInfo などの null 記述子パラメータの場合の動作を明確にします。従来は、MBeanInfo のコンストラクタおよび関連するクラスの仕様では、記述子パラメータに null を入力すると空の記述子が生成されると言われていました。実際、これは、実装によって特定の標準フィールドを追加できる、空の記述子の入力値と同等です。
新しいクラス javax.management.JMX
新しいクラス、
javax.management.JMX
が、定数および静的メソッドを格納するために追加されました。NotificationBroadcaster と NotificationBroadcasterSupport
インタフェース
NotificationBroadcaster
とそのデフォルト実装のNotificationBroadcasterSupport
には、多くの変更点があります。
4506105: 従来は、送信できる通知の型を指定するために
NotificationBroadcasterSupport
をサブクラス化してgetNotificationInfo()
メソッドを上書きする必要がありました。このリリースでは、入力時にMBeanNotificationInfo...
を持つように、新しいコンストラクタが追加されました。4661545: 従来は、通知ディスパッチモデルに同期させるか非同期にさせるかについての仕様が非常にあいまいでした。スレッドが
sendNotification
を呼ぶと、実装クラスによって、各リスナーのNotificationListener.handleNotification
メソッドがそのスレッド (同期モデル) 内、または他のスレッド (非同期モデル) 内に呼び出されました。J2SE 5 では、同期モデルが実装されました。つまり、NotificationBroadcasterSupport
が送信側のスレッドを使用して、すべてのリスナーに通知を送信していました。非同期モデルが必要な場合、ユーザーは、サブクラスを作成し、メソッドhandleNotification
を上書きする必要がありました。Java SE 6 でも、デフォルト設定には同期モデルが採用されています。クラス
NotificationBroadcasterSupport
にコンストラクタが追加され、java.util.concurrent.Executor
をパラメータとして持つようになりました。Executor
は、リスナーへの通知をディスパッチするために使用されます。これにより、非同期モデルが必要な場合でも、サブクラスの作成を回避できます。3 つ目のコンストラクタが、前述した 2 つの機能を統合し、
Executor
とMBeanNotificationInfo...
の両方をパラメータとして持つようになりました。6244863: フィルタまたはリスナーが例外をスローした場合の、NotificationBroadcasterSupport の動作を指定します。従来、JMX 仕様では、通知ブロードキャスタが管理するリスナーやフィルタが例外をスローする際の動作を定義しませんでした。今回、この動作が指定できるようになりました。
Exception
が他のリスナーの呼び出しを妨げることはありません。ただし、Error
はsendNotification
の呼び出し側に伝播されます。6252526: 新しいクラス、
javax.management.StandardEmitterMBean
が追加されました。StandardEmitterMBean
はNotificationEmitter
であるjavax.management.StandardMBean
のサブクラスです。ObjectName
ObjectName
には、多くの変更点があります。
4716807: ObjectName で、
key=*
のワイルドカードがサポートされます。以前は、名前にkey1=value1
を持つ MBean と一致させるためにdomain:key1=value1,*
を使用できましたが、名前にkey1
を持つ MBean と一致させるためにdomain:key1=*
を使うことはできませんでした。ObjectName の機能がこのリリースで拡張され、値のどこにでもワイルドカード (*
および/または?
) を置くことができるようになりました。2 つの新しいメソッド、
isPropertyValuePattern()
とisPropertyValuePattern(String property)
を使用すると、ObjectName が特定のプロパティーの値にワイルドカードを持っているかどうか、また、持っている場合、どのプロパティーであるかを検出できます。4780400: 新しく 2 つのObjectName 定数が追加されました。JMX API のユーザーは、2 つの ObjectName 定数を頻繁に参照する必要があります。
new ObjectName("JMImplementation:type=MBeanServerDelegate") new ObjectName("*:*")このうちの 1 つ目は、覚えにくい上に、間違えると、コードがコンパイルされても機能しません。これらは両方とも、ObjectName コンストラクタが確認済みの例外
MalformedObjectNameException
をスローするという問題の影響を受けます。結果的には、try ブロックや catch ブロックで定数をラップしなければなりません。この状態を改善できるよう、このリリースに新しく 2 つの定数が追加されました。
5036680:
ObjectName
がComparable<ObjectName>
を実装します。Comparable を実装することで、ユーザー定義の Comparator を作成する必要もなく、適切な順番で SortedSetのコンテンツを表示させることができます。詳細については、 ObjectName.compareTo(ObjectName)
を参照してください。6392494: ObjectName のドメインに // が予約されるように指定します。文字列 // は、JMX API の次のバージョンのカスケーディング機能の一部として ObjectName ドメインで使用する予定です。この文字列が実装に対してまだ特に意味を持たない場合でもこの文字列を回避できるように、仕様に警告が追加されました。
標準 MBean
標準 MBean の仕様に次の変更が加えられました。
4949203: 取得メソッドと設定メソッドの呼び出しに関する正しいテキスト。JMX 1.2 仕様ドキュメントでは、Maintenance Review 変更リストごとに、標準 MBean での取得メソッドと設定メソッドは
MBeanServer.invoke
では呼び出せないということを明確にしているはずでした。しかし、この意味でのテキストが、動的 MBean に関するセクションに間違って表示されていました。これは、標準 MBean に関するセクションに明確に置く必要があります。また、このテキストはプロパティー
"jmx.invoke.getters"
にも言及していました。仕様に記述されているため、実装にこのプロパティーを考慮する必要があると判断するユーザーがいたかもしれません。しかし、それは Maintenance Review 中で述べられていることではなく、意図している内容とも違います。どちらかというと、このプロパティーは、リファレンス実装の機能の 1 つで、以前なら、取得メソッドを呼び出せることに間違えて頼っていたかもしれないコードの移行を簡単にするものです。そのため、仕様ではなく、リファレンス実装のリリースノートに記述する必要があります。6190628: 標準 MBean が MBean インタフェースで共変の戻り値型をサポートします。J2SE 5 では、クラスとインタフェースに共変の戻り値型が導入されました。ただし、MBean サーバーは、整合性がない場合、共変型で作成された標準 MBean を拒否しました。このリリースでは、操作 (取得メソッドと設定メソッド以外のメソッド) と、読み取り専用の属性 (対応設定メソッドのない取得メソッド) に対して、共変型を使うことができます。
動的な MBean
動的な MBean に次の変更が加えられました。
6306219: 動的な MBean の
MBeanServer.isInstanceOf
セマンティクスを明確にします。このメソッドの仕様は、true を返すはずの重要なケース (具体的には、MBean の ClassLoader が指定したクラスをロードでき、MBean がそのクラスのインスタンスの場合) を抜かしていました。リファレンス実装は、実際、この場合 true を返しました。これは、DynamicMBean が 自身の MBeanInfo に、インスタンスではないクラス名を返す場合とは異なります。たとえば、javax.management.StandardMBean
(DynamicMBean) のインスタンスは、MBeanInfo (getClassName()
が"javax.management.timer.TimerMBean"
を返す)を返すことができました。現在の仕様では、呼び出しのmbeanServer.isInstanceOf(objectName, "javax.management.StandardMBean")
が false を返す予定です。TimerMBean
は、StandardMBean
のインスタンスではないためです。実際は、true を返しますが、実際の MBean オブジェクトはStandardMBean
のインスタンスです。クラス
StandardEmitterMBean
と MBean がNotificationBroadcaster
であるかどうかを判断するためのisInstanceOf
を使用した既存の例が追加されたことで、仕様を変更して、実装に反映させることが重要になりました。StandardEmitterMBean
は、通常、NotificationBroadcaster
ではないクラス名を持った MBeanInfo を返します。ただし、isInstanceOf(..., "javax.management.NotificationBroadcaster")
に true を返させる必要があります。Model MBean
Model MBean の仕様には、細かい変更点が数多く適用されています。
4883709: Model MBean 記述子の「value」と「displayName」フィールドはイタリック体にする必要があります。これは、PDF 仕様でのバグです。オプションのフィールドはイタリック体にする必要があります (従来は異なりました)。
4997033: setMethod と currencyTimeLimit がない場合、RequiredModelMBean.setAttribute は例外をスローする必要があります。この変更により、PDF と Javadoc テキスト間の矛盾が解決されました。setMethod とキャッシュがない場合にのみ例外がスローされるという仕様が明確なため、
setAttribute
の操作に影響はまずないでしょう。5043245: RequiredModelMBean.getAttribute() で、属性型のチェックが限定的すぎです。戻り値が属性に宣言されているものとまったく同じ型にする必要があるか、それともサブタイプも可能であるかについての仕様があいまいでした。今回の変更で、サブタイプは明示的に許可されました。
5046781: ModelMBeanOperationInfo 記述子の role フィールドがオプションであることを仕様に記述する必要があります。PDF 仕様にはこのフィールドが削除可能であることが明記されているため、リファレンス実装の動作に影響します。
5046784: Model MBean 記述子の targetType の値は大文字と小文字が区別されません。仕様では、自身の例で、このフィールドは大文字と小文字が区別されないことを示唆していますが、大文字小文字が区別されないフィールドの明示的なリストには記述されていませんでした。
5104947: ModelMBeanInfoSupport.clone が deep または shallow であるかどうかを明確にします。仕様が修正され、クローンを shallow にする理由について既存の動作が記述されます。
6175387: 新しい
OnUnregister
persistPolicy の値を Model MBean 記述子に追加します。持続性が Model MBean データでサポートされた場合、MBean 属性の記述子にある persistPolicy 値を使用して、動作方法を定義できます。従来、これらの値は Never、OnUpdate、OnTimer、NoMoreOftenThan、Always でした。このリリースでは、属性値が永続的になることを意味する新しい値、OnUnregister が追加されました。これにより、OnUnregister を含む MBean がサーバーに登録されていない場合、その属性の値が永続的になります。このフィールドを参考にするメソッドの仕様もこれに応じて更新され、RequiredModelMBean.store()
とRequiredModelMBean.setAttribute
に保存されない persistPolicy の値のリストを持つようになりました。6236765: ModelMBeanConstructorInfo に特定のフィールドが無効と表示されますが、チェックしません。従来の ModelMBeanConstructorInfo の仕様では、persistPolicy と currencyTimeLimit フィールドが無効でしたが、リファレンス実装はこれをチェックしませんでした。これらのフィールドを持った可能性のある既存のコードの破壊を避けるため、フィールドの意味はないが無効と判断されないように、今回仕様を変更しました。
6241620: null パラメータに関する DescriptorSupport(String[],Object[]) ドキュメントの矛盾。仕様の矛盾が解決されました。リファレンス実装の動作に反映されます。
6332962: targetObject フィールドを含む DescriptorSupport の直列化に問題があります。Model MBean における属性または操作の記述子には、その属性や、Model MBean 全体で定義されたものから異なるリソースに向かう操作に対する直接のアクセスになる
targetObject
フィールドが含まれる場合があります。そのような場合、その値は直列化が不可能なオブジェクトになる可能性があります。すべてにおいて、直列化不可能なオブジェクトを直列化する意味はありません。そのため、DescriptorSupport の直列化からそれを除外するように仕様を更新し、RequiredModelMBean.getMBeanInfo() が直列化可能なオブジェクトを返すようにしました。Open MBean
Open MBean に対する変更の多くは、ユーザー定義の MXBean が加わることが前提に考えられました。ここに、すべての変更点を示します。
5045358: Open MBean がプリミティブ型の配列を参照できます。従来、Open Bean が参照できた型のセットには、
java.lang.Integer
やjava.lang.Boolean
のようなプリミティブなラッパー型のみ含まれました。ただし、int
やboolean
のようなプリミティブ型は含まれませんでした。今回、これらのプリミティブ型の配列が含まれるようになりました。ArrayType クラスを拡張したため、int[]
のようなプリミティブ型を OpenType として表現できます。この新しい機能を使用することで、MXBean に MXBean インタフェース内のプリミティブ型の配列を、対応する OpenType にマッピングさせることができます。次のメソッドが ArrayType クラスに追加されました。
- javax.management.openmbean.ArrayType.getArrayType(OpenType)
- javax.management.openmbean.ArrayType.getPrimitiveArrayType(Class)
- javax.management.openmbean.ArrayType.isPrimitiveArray()
- javax.management.openmbean.ArrayType(SimpleType,boolean)
今回から、コンストラクタ ArrayType(int dimension, OpenType<?> elementType) で、elementType パラメータが ArrayType のインスタンスになることができます (6252649)。ArrayType.equals と ArrayType.hashcode メソッドは、今回から新しい primitiveArray フラグを考慮できるようになりました。
5095277:
CompositeDataSupport.equals
が要素ごとに配列を比較します。従来は、2 つのCompositeDataSupport
要素がそれぞれ最低 1 つのArrayType
項目を含む同じCompositeType
を持っていた場合、CompositeDataSupport.equals
の呼び出しで、この配列の ID のみが比較されました。その結果、オブジェクトが同じ配列を参照していた場合でも、CompositeDataSupport.equals
は true しか返しませんでした。今回から、CompositeDataSupport.equals
を呼び出すと、配列の要素を 1 つずつ比較するようになりました。そのため、2 つのオブジェクトが同じコンテンツの異なる配列を参照している場合に、true が返されます。CompositeDataSupport.hashCode
にもこれに応じた変更がなされています。6228130:
TabularDataSupport.entrySet()
で戻り値のSet
のキーがList
にラップされるように指定します。従来、戻り値の Set のコンテンツについてドキュメントの定義があいまいでした。今回から、Set<Map.Entry<Object,Object>>
として明確にしていますが、実際にはSet<Map.Entry<List<?>,CompositeData>>
です。互換性の理由から、後者の宣言を直接行うことはできません。6320104: Open MBean の OperationInfo の impact に、UNKNOWN を設定できる機能が追加されます。
MBeanOperationInfo
のimpact
として許可されていた値は、ACTION
、INFO
、ACTION_INFO
、UNKNOWN
です。従来は、この最後の値がOpenMBeanOperationInfoSupport
で許可されませんでした。5072004: CompositeData と CompositeType におけるスキーマの展開のサポートが良くなりました。従来、CompositeType ct が指定された状態で、メソッド javax.management.openmbean.CompositeType.isValue(x) の x が CompositeData の場合、さらに x.getCompositeType() が ct と等しかった場合のみ、javax.management.openmbean.CompositeType.isValue(x) は true を返していました。しかし、今回からこのルールが緩和されました。x.getCompositeType() に返される型は、今回も ct と同じ名前である必要があります。また、ct と同じ項目をすべて持っている必要がありますが、項目を追加することはできます。この変更は、TabularData や配列に含まれる CompositeData 項目に関する TabularType.isValue と ArrayType.isValue のルールにも影響します。
6333582: OpenType は、public static の配列 ALLOWED_CLASSNAMES を宣言するべきではありません。このフィールドは、新しいフィールド ALLOWED_CLASSNAMES_LIST と入れ替わります。
監視サービス
次の変更点が監視サービス (パッケージ
javax.management.monitor
) の仕様に加わりました。
6222961: 監視サービスが複合型をサポートします。従来の監視サービスでは、単純型の属性しか監視できませんでした。そのため、監視が必要な値が、多くの複合型に埋もれてしまうことがあります。たとえば、JSR 77 で定義された J2EE インストゥルメンテーション を処理したあと、サーブレットのサービス時間に監視を設定する場合、そのサーブレットの
ServiceTime
属性を取得して、serviceTime.getMaxTime()
を監視する必要があります。そのため、ServiceTime.maxTime
を監視してこの効果を取得できるように仕様が変更されました。詳細な仕様については、javax.management.monitor
を参照してください。6239455: 監視タスクが呼び出し側の
monitor.start()
のアクセス制御コンテキスト内で実行されるように指定します。セキュリティーが有効な場合、呼び出し側が対象の属性へアクセスできているかどうか、またはその属性の実装が実行する可能性のある、セキュリティーで保護された操作へアクセスできているかどうかを確認するために実行されたセキュリティーチェックは、呼び出し側のmonitor.start()
のアクセス制御コンテキストに基づきます。監視を生成した側のアクセス制御コンテキストではありません。これは、javax.management.monitor
のパッケージドキュメンテーションに記述されています。タイマーサービス
次の変更点がタイマーサービス (パッケージ
javax.management.timer
) の仕様に加わりました。
6235077: javax.management.timer.Timer doc が、過去の日付で発生した内容と整合性がとれませんでした。JMX Specification のバージョン 1.2 より前は、通知が過去の時間にスケジュールされていた場合、タイマーサービスが例外をスローするように定義されていました。バージョン 1.2 からは、このような場合、即座に通知を送信できるような、より論理的な動作が導入されました。しかしながら、javax.management.timer.Timer のドキュメントによっては、まだ古い動作が反映されていました。特に、クラスドキュメントの注記には、過去の時間に対する通知は無視されると記述されていたのに対し、IllegalArgumentException の @throws ドキュメントには、過去の日付にスローされたと記述がありました。
6387340: javax.management.timer.TimerAlarmClockNotification を削除します。 表示されるコンストラクタのみが非 public クラスの型のパラメータを持っているため、このクラスは、定義されたパッケージ以外のコードでは使用できません。このコンストラクタを null パラメータで呼び出した場合、即座に例外を受け取ります。そのため、例外的に、この public クラスを他に影響が出ないように Java SE API から削除できるようにしました。
MLet サービス
次の変更点が MLet サービス (パッケージ
javax.management.loading
) の仕様に加わりました。
4796780: MLetContent クラスは public にする必要があります。最近のリリースでは、
MLet.check
メソッドが public で作成されましたが、そのパラメータの 1 つがjavax.management.loading.MLetContent
型で、そのクラスが private のままでした。そのため、非表示のクラスを参照したパブリックに表示できるメソッドで不整合が発生しました。今回、MLetContent を public にすることでこの問題を修正しました。6223396: ネイティブライブラリの MLet サポートがあいまいであるため、オプションにする必要があります。MLet.findLibrary の仕様が更新され、jar ファイル内のネイティブライブラリの検索に使われるアルゴリズムが記述されるようになりました。また、この機能をサポートしない実装の @throws 節も追加しました。PDF の仕様も同様に更新されました (セクション 8.3.2)。
関係サービス
次の変更点が関係サービス (パッケージ
javax.management.relation
) の仕様に加わりました。
4892674: RelationNotification の直列化の問題。
RelationNotification
コンストラクタは、自身のソースパラメータがRelationService
のインスタンスである必要があり、それらはユーザーに通知を転送する前の、RelationService の ObjectName に対する再書き込みについて、MBean サーバーに頼っています。この設定は不安定で、特に RelationNotification インスタンスの再構築が難しくなります (例: 直列化された XML 形式からの再構築)。コンストラクタを修正することで、ソースをObjectName
にすることも可能としました。5053367: RelationService.addRelationType 仕様が null 関連型の名前を拒否します。RelationService.addRelationType (および RelationServiceMBean.addRelationType) は、RelationType の属性が getRelationTypeName() から null を返した場合、IllegalArgumentException をスローするように明示的に指定されています。RelationService.addRelationType (および RelationServiceMBean.addRelationType) は、RelationType の属性が getRelationTypeName() から null を返した場合、IllegalArgumentException をスローするように明示的に指定されています。関連型の名前を持つ他の RelationService メソッドは、すべて null 名を拒否するように指定されています。そのため、addRelationType が 1 つでも null 名を許可すると、RelationType で何もできなくなってしまう可能性があります。特に、再度削除することもできなくなるでしょう。
6229880: RelationSupport javadoc があいまいです。.
RelationSupport.setRole
は、ロールに書き込みできない場合、RoleNotFoundException をスローするように指定していました。実際、指定の名前に定義されたロールがない場合も、RoleNotFoundException がスローされます (getRole メソッドと同じ状態)。
RelationSupport.setRoles
は、ロール「名」が null の場合、IllegalArgumentException をスローするように指定していました。これは、ロール「リスト」にする必要があります。クエリー
新しい
javax.managent.Query.isInstanceOf(StringValueExp className)
メソッド を使用することで、特定のクラスのインスタンスであるすべての MBean を取得できます (5072174)。MBeanServerInvocationHandler
次の変更点が MBeanServerInvocationHandler の仕様に加わりました。
6177524: MBeanServerInvocationHandler が Object メソッドをプロキシした MBean に転送しなくなりました。従来、MBeanServerInvocationHandler はhashCode()、toString()、equals(Object) メソッドを、プロキシした MBean に転送していました。つまり、MBean プロキシを HashMap のキーとして使用できませんでした (たとえば、プロキシにキャッシュされた MBeanInfo の検索)。今回から、ハンドラの対象になる MBean インタフェースで明示的に記述されている場合にのみ、MBeanServerInvocationHandler はこれらのメソッドを転送します。javax.management.MBeanServerInvocationHandler.invoke メソッドは更新され、問い合わせ中のメソッドがあるかどうかを確認するために、MBean インタフェースを検証するようになりました。
6278707: MBeanServerInvocationHandler は、自身のコンストラクタパラメータの取得の際に、取得メソッドが必要です。
getMBeanServerConnection()
、getObjectName()
、isMXBean()
は新しいメソッドです。新しいメソッド
JMX.newMBeanProxy
は、MBeanServerInvocationHandler.newProxyInstance
の代わりで、より覚えやすくなりました。直列化形式
JMX API におけるクラスの直列化形式の仕様が、次のように明確になりました。
6253903: JMX API の仕様に、直列化可能なすべてのクラスの serialVersionUID がリストされます。実装上の理由から、 Serialized Form ページ (Javadoc 生成の仕様) は、特定のクラスの
serialVersionUID
を削除します。独立した実装では準拠情報としてこの情報が必要になるため、必要な場合、自身のクラスの仕様内で提供されました。6344759: 12 の
javax.management.*Exp
private クラスをより明確にする必要があります。実装間で相互運用する場合、さまざまな静的Query.*
メソッド (Query.and
など) に返された値は、指定の非 public クラスである必要があります。または、少なくとも適宜直列化される必要があります。これに応じて、これらのメソッドの仕様が更新されています。アクセス権のチェック
従来、JMX の仕様には、null でない SecurityManager がある場合 (またはある場合のみ)、アクセス権のチェックが実行されるように記述されていました。これが変更され、SecurityManager の有無を確認する必要がない記述に変更されました。つまり、今回から、実装は SecurityManager が存在しない場合でも、チェックを実行するかどうかを選択できます。 (6419572)MBean RuntimeException 処理
JMX の仕様は、MBean の属性や操作を実装しているメソッドが RuntimeException をスローした場合、何が発生するかについて記述があいまいでした (5043152)。綿密に解釈すると RuntimeMBeanException の例外をラップする必要があることがわかりましたが、RuntimeOperationsException でそれをラップできないかは明確ではありませんでした。今回、RuntimeMBeanException について仕様に明示的に記述され、また、RuntimeOperationsException が MBean メソッドが呼び出される前に (null 属性を持つ getAttribute など) 発生する例外をラップすることも明示的に記述されました。
Model MBeans は、RuntimeMBeanException ではなく、RuntimeOperationsException の ManagedResource で呼び出されたメソッドから来る例外をラップします。
これは明確に指定されていませんでしたが、変更した場合、既存のコードが壊れる可能性がありました。そのため、既存の動作だけでなく、MBean が 以降はラップされない RuntimeOperationsException をスローする条件も明確に指定しました。JMX Remote API
次の変更点がJMX Remote API の仕様に加わりました。
6343209: SubjectDelegationPermission が ConnectorServer 作成側に対して、どのように機能するかを指定します。JMXConnectorServer の作成側は、コネクタ サーバーに作成された接続が使用するすべてのアクセス権を持つ必要がなくなりました。その代わり、それぞれリモートで認証された ID の SubjectDelegationPermission を持つことができます。これにより、セキュリティーを重視した環境での配備が簡単になります。
5021246: RMI コネクタの仕様に、該当する場合コードのダウンロードを使用するように記述します。RMI コネクタは、該当する場合、「Java RMI の使用による動的なコードのダウンロード」の記事に指定されているとおりにコードのダウンロードを使用します。リファレンス実装が常にこの方法で動作してきたため、それを反映できるように、仕様が更新されました。
6375696: JMX Remote API の CORBA Tie クラスは、javax.management.remote.rmi に含める必要があります。OMG の「IDL to Java Language Mapping Specification」に準拠する場合、javax.management.remote.rmi.RMIServerImpl や javax.management.remote.rmi.RMIConnectionImpl のリモートオブジェクトの CORBA の「Tie クラス」が javax.management.remote.rmi パッケージに含まれる必要があります。
6231888: JMXConnector は、Closeable を実装します。 インタフェース
java.io.Closeable
は、IOException をスローする単一の
public void close()
メソッドを定義します。JMXConnector
には、同一の署名を持つメソッドが含まれるため、JMXConnector
インタフェースはCloseable
インタフェースを拡張できます。6234398: JMX 接続プロバイダの API 例外処理があいまいです。インタフェース
JMXConnectorProvider
とJMXConnectorServerProvider
が明確になりました。URL のプロトコルがプロバイダに認識されない場合、これらのメソッドがMalformedURLException
をスローします。また、その URL に対して適切なプロバイダが何らかの理由で使用できない場合は、JMXProviderException
をスローします。他の場合は、他のIOException
をスローします。6238076:
javax.management.remote.rmi.RMIConnector
の直列化形式にclientNotifID
フィールドが含まれています。このフィールドは、偶然、直列化形式に含まれました。このフィールドの目的は、RMIConnector
からのJMXConnectionNotification
の通知シーケンス番号を追跡することです。通常、RMIConnector
は、RMIConnectorServer.toJMXConnector の戻り値である場合にのみ、直列化されます(接続されなかったり、シーケンス番号が 0 の場合)。
RMIConnector
が他の条件で直列化された場合でも、その後直列化が復元されれば、通知シーケンス番号が継続されることはまずありません。6238815: コネクタクライアントが接続されているアドレスを取得する方法を追加します。新しいインタフェース
JMXAddressable
を指定のコネクタクライアントに実装させることができます。実装させた場合、JMXConnector
インスタンスをJMXAddressable
にキャストしてgetAddress()
を呼び出し、クライアントが接続されているアドレスを検出できます。RMI クライアントの接続が指定され、このインタフェースが実装されます。JMXConnectorServer
クラスも既存のgetAddress()
メソッドを使用して、このインタフェースを実装します。
Copyright © 2006 Sun Microsystems, Inc.
All Rights Reserved. フィードバック |
|