@Documented @Retention(value=RUNTIME) @Target(value=TYPE) public @interface MXBean
インタフェースに対して、MXBean インタフェースである、または MXBean インタフェースではないというマークを明示的に付けるための注釈です。デフォルトでは、SomethingMXBean
のように名前の末尾が MXBean
の場合、そのインタフェースは MXBean インタフェースです。次に示すインタフェースは、MXBean インタフェースです。
public interface WhatsitMXBean {} @MXBean public interface Whatsit1Interface {} @MXBean(true) public interface Whatsit2Interface {}
次に示すインタフェースは、MXBean インタフェースではありません。
public interface Whatsit3Interface{} @MXBean(false) public interface MisleadingMXBean {}
MXBean の概念を使用すると、javax.management.openmbean
により定義された、定義済みの型セットだけを参照する MBean を簡単にコーディングできます。この方法なら、リモートクライアントを含むクライアントは、MBean の型を示すモデル固有のクラスにアクセスしなくても、MBean を利用できます。
この概念は、Standard MBean の概念と比べて、理解しやすいものです。ここでは、管理対象オブジェクトを Standard MBean および MXBean として表現する方法について説明します。
Standard MBean | MXBean |
---|---|
public interface MemoryPoolMBean { String getName(); MemoryUsage getUsage(); // ... } |
public interface MemoryPoolMXBean { String getName(); MemoryUsage getUsage(); // ... } |
上記の記述から、定義は非常に類似していることがわかります。唯一の相違点は、インタフェースの命名規則として、Standard MBean では SomethingMBean
を使用するのに対して、MXBean では SomethingMXBean
を使用するという点です。
この管理対象オブジェクトでは、MemoryUsage
型の Usage
という名前の属性があります。この種の属性の特徴は、データ項目セットの一貫したスナップショットを提供する点です。たとえば、メモリープール内の現在の使用済みメモリー容量や、現在のメモリープールの最大値を含めることができます。これらが別の項目になっていると、getAttribute
を個別に呼び出して項目を取得するため、さまざまな時点の一貫性のない値を取得する可能性があります。max
値よりも大きい used
値を取得する可能性もあります。
このため、次のように MemoryUsage
を定義できます。
Standard MBean | MXBean |
---|---|
public class MemoryUsage implements Serializable { // standard JavaBean conventions with getters public MemoryUsage(long init, long used, long committed, long max) {...} long getInit() {...} long getUsed() {...} long getCommitted() {...} long getMax() {...} } |
public class MemoryUsage { // standard JavaBean conventions with getters @ConstructorProperties({"init", "used", "committed", "max"}) public MemoryUsage(long init, long used, long committed, long max) {...} long getInit() {...} long getUsed() {...} long getCommitted() {...} long getMax() {...} } |
MXBean では MemoryUsage
に Serializable
のマークを付ける必要がないことを除けば、どちらの場合も定義は同じです (ただし、Serializable のマークを付けることは可能)。一方、MXBean には、コンストラクタパラメータを対応する getter にリンクするための、@ConstructorProperties
注釈が追加されています。この点については、あとで詳しく説明します。
MemoryUsage
は、モデル固有クラスです。Standard MBean では、MemoryUsage
クラスが不明な場合、MBean サーバーのクライアントは Usage
属性にアクセスできません。クライアントが、JMX 技術に基づくジェネリックコンソールである場合を考えてみましょう。この場合、コンソールは、接続先の各アプリケーションのモデル固有クラスを使って設定する必要があります。Java 言語で記述されていないクライアントの場合、問題は一層難しくなります。この場合、MemoryUsage
の内容についてクライアントに知らせる方法がない可能性があります。
このような場合に、MXBean は Standard MBean と異なります。管理インタフェースの定義方法はほとんど同じですが、MXBean フレームワークでは、モデル固有クラスが Java プラットフォームの標準クラスに変換されます。配列および標準 javax.management.openmbean
パッケージの CompositeData
クラスと TabularData
クラスを使用することで、標準クラスだけを使用して任意の複雑さのデータ構造を構築できます。
この点は、2 つのモデルのクライアントを比較することでより明確になります。
Standard MBean | MXBean |
---|---|
String name = (String)
mbeanServer. |
String name = (String) mbeanServer. |
String
などの単純な型の属性の場合、コードは同じです。ただし、複雑な型の属性の場合、Standard MBean のコードではクライアントがモデル固有クラス MemoryUsage
を認識する必要があるのに対し、MXBean のコードでは非標準クラスは必要ありません。
ここに示すクライアントコードでは、MXBean クライアントの方がいくらか複雑になっています。ただし、クライアントがモデル (ここでは、MemoryPoolMXBean
インタフェースと MemoryUsage
クラス) を実際に認識している場合は、プロキシの構築が可能です。モデルが事前にわかる場合には、Standard MBean を使用するか MXBean を使用するかに関係なく、この方法で管理対象オブジェクトとのやり取りを行うことをお勧めします。
Standard MBean | MXBean |
---|---|
MemoryPoolMBean proxy =
JMX. |
MemoryPoolMXBean proxy =
JMX. |
MemoryPool オブジェクトの実装の動作は、Standard MBean でも MXBean でも同様です。
Standard MBean | MXBean |
---|---|
public class MemoryPool implements MemoryPoolMBean { public String getName() {...} public MemoryUsage getUsage() {...} // ... } |
public class MemoryPool implements MemoryPoolMXBean { public String getName() {...} public MemoryUsage getUsage() {...} // ... } |
MBean Server への MBean の登録の動作は、どちらの場合も同じです。
Standard MBean | MXBean |
---|---|
{
MemoryPoolMBean pool = new MemoryPool();
mbeanServer. |
{
MemoryPoolMXBean pool = new MemoryPool();
mbeanServer. |
MXBean は、MBean の一種です。MXBean オブジェクトは、MBean サーバーに直接登録することも、StandardMBean
の引数として使用し、結果の MBean を MBean サーバーに登録することもできます。
MBeanServer
インタフェースの registerMBean
や createMBean
メソッドを使ってオブジェクトを MBean サーバーに登録すると、MBean の型を判別するためにオブジェクトのクラスが検査されます。
DynamicMBean
インタフェースを実装する場合、MBean は Dynamic MBean です。StandardMBean
クラスはこのインタフェースを実装します。このため、これは StandardMBean
クラスを使って作成された Standard MBean または MXBean に適用されます。SMXBean
のインタフェース (S
は空ではない文字列であり、注釈 @MXBean(false)
を含まない); および/または@MXBean(true)
または単に @MXBean
という注釈を含むインタフェース。MemoryPoolMXBean
です。
NotCompliantMBeanException
が生成されます。
MXBean インタフェース内でメソッドのパラメータまたは戻り値の型として示されるすべての Java 型が、次のルールに従って変換可能である必要があります。また、パラメータが次の定義に従って再構築可能である必要があります。
上記のルールに準拠しない MXBean を構築しようとすると、例外がスローされます。
MXBean 内のメソッドには、Standard MBean 内のメソッドと同じ命名規則が適用されます。
T getN()
メソッド (T
は void
ではない Java 型、N
は空でない文字列) は、N
という名前の読み取り可能な属性が存在することを示します。属性の Java 型および公開型は、次のマッピングルールに従って決定されます。Object
から継承した final Class getClass()
メソッドは、getter の検索時には無視されます。boolean isN()
メソッドは、Java 型 boolean
および公開型 SimpleType.Boolean
の読み取り可能属性 N
が存在することを示します。void setN(T x)
メソッドは、書き込み可能属性 N
が存在することを示します。属性の Java 型および公開型は、次のマッピングルールに従って決定されます。パラメータの名前 x
は関係ありません。getN
および isN
のルールにより、getter の概念がまとめて定義されます。setN
のルールにより、setter の概念が定義されます。
同名の getter が 2 つ存在するか、同名の setter が 2 つ存在するとエラーになります。同名の getter と setter が存在する場合は、両方の T
型を同じにします。この場合、属性は読み取り/書き込み属性になります。getter と setter のいずれか一方が 1 つだけ存在する場合、属性はそれぞれ読み取り専用または書き込み専用になります。
javax.management.openmbean
パッケージで定義されているように、MXBean は Open MBean の一種です。これは、属性、演算パラメータ、および演算の戻り値がすべて、公開型 (つまり OpenType
の 4 つの標準サブクラス) を使って記述可能でなければならないことを意味します。MXBean では、Java 型を公開型にマッピングすることでこれを実現します。
すべての Java 型 J で、MXBean マッピングの記述に次の情報が使用されます。
OpenType
のサブクラスのインスタンスです。たとえば、Java 型 List<String>
について考えてみましょう。
List<String>
) は ArrayType
(1,
SimpleType.STRING
)
であり、1 次元の String
配列を表します。List<String>
) は String[]
です。List<String>
は、List.toArray(new String[0])
を使って String[]
に変換できます。String[]
は、Arrays.asList
を使って List<String>
に変換できます。J から opentype(J) を派生させるマッピングルールが存在しない場合、J を MXBean インタフェース内のメソッドパラメータまたは戻り値の型にすることはできません。
opendata(J) を J に再変換する方法がある場合、J は再構築可能であると言います。MXBean インタフェース内のすべてのメソッドパラメータは、再構築可能である必要があります。これは、MXBean フレームワークがメソッドを呼び出す際に、これらのパラメータを opendata(J) から J に変換する必要があるためです。JMX.newMXBeanProxy
により生成されたプロキシでは、これは、再構築可能でなければならない MXBean インタフェース内のメソッドの戻り値です。
null 値を使用できないプリミティブ Java 型を除く、すべての Java 型と公開型で、null 値が許可されます。J 型を opendata(J) 型に変換したり、opendata(J) 型を J 型に変換したりする場合は、null 値と null 値がマッピングされます。
次の表に、型マッピングルールの概要を示します。
Java 型 J | opentype(J) | opendata(J) |
---|---|---|
int 、boolean など(8 つのプリミティブ Java 型) |
SimpleType.INTEGER 、SimpleType.BOOLEAN など |
Integer 、Boolean など(対応する boxed 型) |
Integer 、ObjectName など( SimpleType の適用範囲内の型) |
対応する SimpleType |
J、同じ型 |
int[] など(プリミティブ要素型の 1 次元配列) |
ArrayType.getPrimitiveArrayType(int[].class) など |
J、同じ型 |
E[] (非プリミティブ要素型 E の配列、 int[][] を含む。E は int[] ) |
ArrayType.getArrayType( opentype(E)) |
opendata(E)[] |
List< E> Set< E> SortedSet< E> (下記を参照) |
E[] に対するものと同じ |
E[] に対するものと同じ |
列挙 E (Java 内で enum E {...} として宣言される) |
SimpleType.STRING |
String |
Map< K,V> SortedMap< K,V> |
TabularType (下記を参照) |
TabularData (下記を参照) |
MXBean インタフェース | SimpleType.OBJECTNAME (下記を参照) |
ObjectName (下記を参照) |
その他の型 | 可能な場合には CompositeType (下記を参照) |
CompositeData |
以降のセクションでは、これらのルールについて詳しく説明します。
8 つのプリミティブ Java 型 (boolean
、byte
、short
、int
、long
、float
、double
、char
) は、java.lang
から Boolean
、Byte
などの対応する boxed 型にマッピングされます。公開型は、対応する SimpleType
です。このため、opentype(long
) は SimpleType.LONG
に、opendata(long
) は java.lang.Long
になります。
long[]
などのプリミティブ型の配列は、公開型として直接表現できます。このため、openType(long[]
) は ArrayType.getPrimitiveArrayType(long[].class)
に、opendata(long[]
) は long[]
になります。
JMX API 内の演算はプリミティブではなく常に Java オブジェクト上で実行されるため、実際には、プレーンな int
と Integer
の違いなどが明確になることはありません。ただし、配列で違いが明らかになります。
List<
E>
など)List<
E>
や Set<
E>
(List<String>
や Set<ObjectName>
など) のマッピング方法は、同じ要素型の配列 (String[]
や ObjectName[]
など) と同じです。
SortedSet<
E>
も E[]
と同じ方法でマッピングされます。ただし、これが変換可能なのは、E が Comparable
を実装するクラスまたはインタフェースである場合だけです。このため、SortedSet<String>
や SortedSet<Integer>
は変換可能ですが、SortedSet<int[]>
や SortedSet<List<String>>
は変換不可能です。SortedSet
インスタンスの変換は、null 以外の comparator()
が存在すると、IllegalArgumentException
をスローして失敗します。
List<
E>
は java.util.ArrayList<
E>
として、Set<
E>
は java.util.HashSet<
E>
として、SortedSet<
E>
は java.util.TreeSet<
E>
としてそれぞれ再構築されます。
Map<
K,V>
など)Map<
K,V>
または SortedMap<
K,V>
(Map<String,ObjectName>
など) は、公開型 TabularType
を持ち、TabularData
にマッピングされます。TabularType
には、key
および value
という名前の 2 つの項目が含まれます。key
の公開型は opentype(K)、value
の公開型は opentype(V) です。TabularType
のインデックスは、単一の項目 key
です。
たとえば、Map<String,ObjectName>
の TabularType
は、次のようなコードを使って構築できます。
String typeName = "java.util.Map<java.lang.String, javax.management.ObjectName>"; String[] keyValue = new String[] {"key", "value"}; OpenType[] openTypes = new OpenType[] {SimpleType.STRING, SimpleType.OBJECTNAME}; CompositeType rowType = new CompositeType(typeName, typeName, keyValue, keyValue, openTypes); TabularType tabularType = new TabularType(typeName, typeName, rowType, new String[] {"key"});
typeName
は、次に詳述する型名ルールに従って決定されます。
SortedMap<
K,V>
は同じ方法でマッピングされます。ただし、これが変換可能なのは、K が Comparable
を実装するクラスまたはインタフェースである場合だけです。このため、SortedMap<String,int[]>
は変換可能ですが、SortedMap<int[],String>
は変換不可能です。SortedMap
インスタンスの変換は、null 以外の comparator()
が存在すると、IllegalArgumentException
をスローして失敗します。
Map<
K,V>
は java.util.HashMap<
K,V>
として、SortedMap<
K,V>
は java.util.TreeMap<
K,V>
としてそれぞれ再構築されます。
TabularData
はインタフェースです。Map<
K,V>
を公開データとして表現するのに使用される具象クラスは TabularDataSupport
、または TabularDataSupport
として直列化する TabularData
を実装する別のクラスです。
MXBean インタフェース、または MXBean インタフェース内部で参照される型は、別の MXBean インタフェース J を参照できます。この場合、opentype(J) は SimpleType.OBJECTNAME
、opendata(J) は ObjectName
です。
たとえば、次のような 2 つの MXBean インタフェースが存在する場合を考えましょう。
public interface ProductMXBean { public ModuleMXBean[] getModules(); } public interface ModuleMXBean { public ProductMXBean getProduct(); }
ModuleMXBean
インタフェースを実装するオブジェクトは、その getProduct
メソッドから、ProductMXBean
インタフェースを実装するオブジェクトを返します。ModuleMXBean
オブジェクトと返される ProductMXBean
オブジェクトの両方を、同じ MBean サーバーの MXBean として登録する必要があります。
ModuleMXBean.getProduct()
メソッドは、Product
という名前の属性を定義します。この属性の公開型は SimpleType.OBJECTNAME
です。対応する ObjectName
値は、参照される ProductMXBean
が MBean サーバー内で登録される名前になります。
ModuleMXBean
用の MXBean プロキシを作成して、その getProduct()
メソッドを呼び出す場合、別の MXBean プロキシを作成することにより、プロキシが ObjectName
を ProductMXBean
に再度マッピングします。つまり、JMX.newMXBeanProxy(mbeanServerConnection, objectNameX, interfaceX)
を使って作成されたプロキシが objectNameY
を別の MXBean インタフェースである interfaceY
に再度マッピングする必要がある場合、JMX.newMXBeanProxy(mbeanServerConnection, objectNameY, interfaceY)
が使用されます。この実装では、同じパラメータを使って JMX.newMXBeanProxy
を呼び出すことで、以前に作成されたプロキシが返されることがあります。また、新規プロキシが作成されることもあります。
ModuleMXBean
インタフェースを次のように変更することで、逆マッピングを実行できます。
public interface ModuleMXBean { public ProductMXBean getProduct(); public void setProduct(ProductMXBean c); }
setProduct
メソッドの存在は、Product
属性が読み取り/書き込みであることを示します。以前と同様に、この属性の値は ObjectName
になります。この属性を設定する場合は、ObjectName
を setProduct
メソッドで必要な ProductMXBean
オブジェクトに変換します。このオブジェクトは、同じ MBean サーバー内の指定された ObjectName
の MXBean プロキシになります。
ModuleMXBean
用の MXBean プロキシを作成してその setProduct
メソッドを呼び出す場合、プロキシはその ProductMXBean
引数を ObjectName
に再度マッピングします。これが機能するのは、引数が実際に、同じ MBeanServerConnection
内の ProductMXBean
に対応する別のプロキシである場合だけです。プロキシは、別のプロキシから返されることがあります (たとえば、ModuleMXBean.getProduct()
は ProductMXBean
用のプロキシを返す)。また、JMX.newMXBeanProxy
により作成されることも、MBeanServerInvocationHandler
またはサブクラスである呼び出しハンドラを持つ Proxy
を使って作成されることもあります。
2 つの異なる ObjectName
に同じ MXBean が登録されていると、別の MXBean からその MXBean への参照があいまいになります。このため、MBean サーバーに登録済みの MXBean オブジェクトを、別の名前で同じ MBean サーバーに登録しようとすると、InstanceAlreadyExistsException
がスローされます。一般に、1 つの MBean オブジェクトを複数の名前で登録することは避けてください。特に、NotificationBroadcaster
である MBean では、正しく動作しません。
Java クラスやインタフェース J が上記の表に示したそのほかのルールに当てはまらない場合、次に示すように、MXBean フレームワークにより CompositeType
へのマッピングが試みられます。この CompositeType
の型名は、次の型名ルールに従って決定されます。
getter のクラスは、上記の規則を使って検査されます。(getter は public インスタンスメソッドでなければならない)。getter が存在しないか、getter の型が変換不可能な場合、J は変換不可能です。
1 つ以上の getter が存在し、どの getter にも変換可能な型が存在する場合、opentype(J) は各 getter 用の項目を 1 つ保持する CompositeType
です。次の getter の場合、
T getName()
CompositeType
内の項目は name
と呼ばれ、opentype(T) 型を持ちます。たとえば、次の項目の場合、
String getOwner()
項目は owner
と呼ばれ、公開型 SimpleType.STRING
を持ちます。次の getter の場合、
boolean isName()
CompositeType
内の項目は name
と呼ばれ、SimpleType.BOOLEAN
型を持ちます。
最初の文字 (コードポイント) が、小文字に変換されることに留意してください。これは Java Beans の規則に従っています。歴史的な理由から、これは Standard MBean の規則とは異なります。Standard MBean または MXBean インタフェースでは getOwner
メソッドは Owner
という名前の属性を定義し、Java Bean またはマップされた CompositeType
では getOwner
メソッドは owner
という名前のプロパティーまたは項目を定義します。
2 つのメソッドが同じ項目名を生成する場合 (getOwner
と isOwner
、getOwner
と getowner
など)、型の変換は不可能です。
公開型が CompositeType
の場合、対応するマップされた Java 型 (opendata(J)) は CompositeData
になります。J のインスタンスから、上記の CompositeType
に対応する CompositeData
へのマッピングは、次のように実行されます。最初に、J が CompositeDataView
インタフェースを実装する場合、そのインタフェースの toCompositeData
メソッドが呼び出されて、変換が実行されます。それ以外の場合は、項目ごとに getter を呼び出して対応する公開データ型に変換することにより、CompositeData
が構築されます。これにより、次のような getter が、
List<String> getNames()
名前「names
」および公開型 ArrayType(1, SimpleType.STRING)
の項目にマッピングされます。CompositeData
への変換により getNames()
が呼び出され、生成された List<String>
が項目「names
」の String[]
に変換されます。
CompositeData
はインタフェースです。型を公開データとして表現するのに使用される具象クラスは、CompositeDataSupport
、または CompositeDataSupport
として直列化する CompositeData
を実装する別のクラスです。
CompositeData
から Java 型 J のインスタンスを再構築するopendata(J) が Java 型 J の CompositeData
である場合、J のインスタンスを CompositeData
から再構築可能であるか、J は再構築不可能であるかのどちらかになります。CompositeData
内のいずれかの項目が再構築不可能である場合、J も再構築不可能です。
指定した任意の J に関して、CompositeData
から J のインスタンスを再構築する方法を決定する際、次のルールが適用されます。リスト内で適用可能な最初のルールが使用されます。
J が
public static
J from(CompositeData cd)
メソッドを持つ場合、そのメソッドを呼び出すことで J のインスタンスが再構築されます。
それ以外で、J が ConstructorProperties
注釈を含む 1 つ以上の public コンストラクタを持つ場合は、これらのコンストラクタの 1 つ (常に同じコンストラクタである必要はない) を呼び出して、J のインスタンスが再構築されます。これらのすべての注釈は、コンストラクタが持つパラメータと同じだけの文字列をリストに含める必要があります。各文字列は J の getter に対応するプロパティーの名前にします。この getter の型は、対応するコンストラクタパラメータと同じにする必要があります。ConstructorProperties
注釈に記述されていない getter が存在するとしても、それはエラーではありません。これらは、オブジェクトの再構築には不要な情報に関連したメソッドである可能性があります。
J のインスタンスは、CompositeData
から再構築された適切な項目を使ってコンストラクタを呼び出すことで再構築されます。この CompositeData
は、一部の項目が存在していなかった以前のバージョンの J に由来するものである可能性があります。このため、呼び出されるコンストラクタは、CompositeData
内に実在する項目に基づいて実行時に決定されます。コンストラクタが適用可能になるのは、ConstructorProperties
注釈に記載されたすべてのプロパティーが CompositeData
内に項目として存在する場合です。適用可能なコンストラクタが存在しない場合は、J を再構築する試みは失敗します。
プロパティーを任意に組み合わせる場合は、次のいずれかが当てはまります。(a) 適用可能なコンストラクタが存在しない、(b) 適用可能なコンストラクタが 1 つだけ存在する、(c) 適用可能なコンストラクタの 1 つが、ほかの適用可能な各コンストラクタが指定したプロパティーの適切なスーパーセットを指定する。つまり、選択するコンストラクタに関してあいまいさは存在しないことになります。この条件が true でない場合、J は再構築可能ではありません。
それ以外で、J が引数のない public コンストラクタを持ち、型が T で名前が N の J 内の各 getter に対して同じ名前と型の対応する setter が存在する場合は、J のインスタンスが引数のないコンストラクタを使って構築され、setter が CompositeData
から再構築された項目を使って呼び出されて値が復元されます。たとえば、
public List<String> getNames()
メソッドが存在する場合、このルールが適用される
public void setNames(List<String> names)
メソッドも存在する必要があります。
CompositeData
が J の以前のバージョンに基づく場合、一部の項目が存在しない可能性があります。この場合、対応する setter は呼び出されません。
それ以外で、J が getter 以外のメソッドを持たないインタフェースである場合、J のインスタンスは、Proxy
を使って構築されます。その際、変換対象の CompositeData
を利用する CompositeDataInvocationHandler
が使用されます。
それ以外の場合、J は再構築不可能です。
次の例では、int
および String
で構成される NamedNumber
型をコーディングするいくつかの方法を示します。いずれの場合でも、CompositeType
は次のようになります。
CompositeType
( "NamedNumber", // typeName "NamedNumber", // description new String[] {"number", "name"}, // itemNames new String[] {"number", "name"}, // itemDescriptions new OpenType[] {SimpleType.INTEGER, SimpleType.STRING} // itemTypes );
from
メソッド:
public class NamedNumber { public int getNumber() {return number;} public String getName() {return name;} private NamedNumber(int number, String name) { this.number = number; this.name = name; } public static NamedNumber from(CompositeData cd) { return new NamedNumber((Integer) cd.get("number"), (String) cd.get("name")); } private final int number; private final String name; }
@ConstructorProperties
注釈を含む public コンストラクタ:
public class NamedNumber { public int getNumber() {return number;} public String getName() {return name;} @ConstructorProperties({"number", "name"}) public NamedNumber(int number, String name) { this.number = number; this.name = name; } private final int number; private final String name; }
public class NamedNumber { public int getNumber() {return number;} public void setNumber(int number) {this.number = number;} public String getName() {return name;} public void setName(String name) {this.name = name;} public NamedNumber() {} private int number; private String name; }
public interface NamedNumber { public int getNumber(); public String getName(); }
データのコレクションを表現するだけのクラスは、通常、不変にしておくことをお勧めします。不変クラスのインスタンスは、構築後に変更することはできません。CompositeData
自体は不変であることに留意してください。不変であることには多数の利点があります。特にスレッドの安全性やセキュリティー面で大きなメリットがあります。このため、setter の使用は、可能な場合は避けるようにしてください。
再帰 (自己参照) 型を MXBean インタフェース内で使用することはできません。これは、CompositeType
の不変性によるものです。たとえば、次の型は自身を参照するため、属性の型になることはできません。
public interface Node { public String getName(); public int getPriority(); public Node getNext(); }
このような再帰型を書き換えて、再帰型でなくすることはいつでも可能です。それには、新しい型を導入することが必要な場合があります。たとえば、
public interface NodeList { public List<Node> getNodes(); } public interface Node { public String getName(); public int getPriority(); }
MXBean は、Open MBean の一種です。ただし、互換性を維持するため、MBeanInfo
は OpenMBeanInfo
と異なっています。特に、属性、パラメータ、オペレーションの戻り値の型が int
などのプリミティブ型または void
(戻り値の型) である場合、属性、パラメータ、オペレーションはそれぞれ MBeanAttributeInfo
、MBeanParameterInfo
、MBeanOperationInfo
で表されます。これらの getType()
または getReturnType()
はプリミティブ名 (「int
」など) を返します。上記のマッピングルールで、opendata マッピングがラップされる型 (Integer
など) と指定される場合でも、これは当てはまります。
MXBean の MBeanInfo.getConstructors()
が返す public コンストラクタの配列 (MBean サーバーに直接登録される) には、その MXBean の public コンストラクタがすべて含まれます。MXBean のクラスが public ではない場合、コンストラクタも public でないとみなされます。StandardMBean
クラスを使って構築される MXBean に対して返されるリストは、Standard MBean と同じ方法で取得されます。MXBean の構築方法に関係なく、コンストラクタパラメータは MXBean マッピングルールの影響を受けず、対応する OpenType
を持ちません。
MBeanサーバー内に直接登録される MXBean が NotificationBroadcaster
インタフェースを実装しない場合、その MXBean の MBeanInfo.getNotifications()
が返す通知型の配列は空になります。それ以外の場合、これは、MXBean の登録時に NotificationBroadcaster.getNotificationInfo()
を呼び出した結果になります。その後、このメソッドの結果が変わっても、MBeanInfo.getNotifications()
の結果は変わりません。StandardMBean
または StandardEmitterMBean
クラスを使って構築される MXBean に対して返されるリストは、Standard MBean と同じ方法で取得されます。
MBeanInfo
に含まれるすべての MBeanAttributeInfo
、MBeanParameterInfo
、および MBeanOperationInfo
オブジェクトの Descriptor
は、上記のマッピングルールで指定された OpenType
を値とするフィールド openType
を持ちます。このため、getType()
が「int
」であっても、getDescriptor().getField("openType")
は SimpleType.INTEGER
になります。
これらの各オブジェクトの Descriptor
も、MXBean インタフェース内に表示される Java 型を表す文字列である originalType
フィールドを持ちます。この文字列の書式については、下記の「型名」セクションを参照してください。
MBeanInfo
の Descriptor
は、文字列「true
」を値とする mxbean
フィールドを持ちます。
MXBean 内のメソッドパラメータや戻り値のマップされていない型 T を文字列として表現することが必要な場合があります。T がジェネリック型でない場合、この文字列は Class.getName()
により返される値になります。それ以外の場合、これは genericstring(T) の値になります。次にこの定義を示します。
Class.getName()
により返される値になります ("int"
、"java.lang.String"
など)。
"[]"
を付加したものになります。たとえば、genericstring(int[]
) は "int[]"
、genericstring(List<String>[][]
) は "java.util.List<java.lang.String>[][]"
になります。
List<String>
などのパラメータ化された型になります。genericstring(T) はClass.getName()
により返されるパラメータ化された型の完全指定名、左山括弧 ("<"
)、genericstring(A) (A は最初の型パラメータ)、2 番目の型パラメータ B が存在する場合は ", "
(コンマと空白文字 1 つ) と genericstring(B)、および右山括弧 (">"
) で構成されます。
メソッドが int[]
を返す場合は、これは、Class.getName()
により返される文字列 "[I"
で表されます。ただし、メソッドが List<int[]>
を返す場合、これは文字列 "java.util.List<int[]>"
で表されます。
Java 型から公開型へのマッピングで問題が発生すると、OpenDataException
により通知されます。これは、getter を持たない java.util.Random
などの型を参照する場合など、MXBean インタフェースの分析中に発生することがあります。また、インスタンスの変換中 (MXBean 内のメソッドからの戻り値または MXBean プロキシ内のメソッドへのパラメータ) に発生することもあります。たとえば、SortedSet
が null 以外の Comparator
を持つ場合に、SortedSet<String>
から String[]
に変換するときに発生します。
公開型から Java 型へのマッピングで問題が発生すると、InvalidObjectException
により通知されます。これは、再構築可能な型が必須のコンテキストで、上記のルールに従うと再構築可能ではない型を参照する場合など、MXBean インタフェースの分析中に発生することがあります。また、該当する名前の Enum 定数が存在しない状況で String から Enum への変換を行う場合のように、インスタンスの変換中 (MXBean 内のメソッドへのパラメータまたは MXBean プロキシ内のメソッドからの戻り値) に発生することもあります。
コンテキストに応じて、OpenDataException
または InvalidObjectException
を、RuntimeMBeanException
や UndeclaredThrowableException
などの別の例外内にラップできます。スローされる各例外で、条件 C が true になります。「e は OpenDataException
または InvalidObjectException
(必要に応じて)。あるいは e.getCause()
の C は true」。
修飾子と型 | オプションの要素と説明 |
---|---|
boolean |
value
注釈付きインタフェースが MXBean インタフェースである場合、true になります。
|
バグまたは機能を送信
詳細な API リファレンスおよび開発者ドキュメントについては、Java SE のドキュメントを参照してください。そのドキュメントには、概念的な概要、用語の定義、回避方法、有効なコード例などの、開発者を対象にしたより詳細な説明が含まれています。
Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.