2011-04-05 17 views
3

通知を発行するMBeanを定義する際のガイドライン、特に通知の種類を調べる。オラクルのサイトにあるJMX Best Practicesには次のような記述があります。しかしそれは少し古くてJava6以前のものです。JMX通知を発行するためのベストプラクティス

通知は、javax.management.Notificationのインスタンスまたはjavax.management名前空間のサブクラスの1つである必要があります。これらのサブクラスのいずれかに収まらない情報は、setUserDataメソッドを使用して通知にCompositeDataを添付することによって伝えられます。

また、Oracleのサイトでは、Weblogicが独自のサブクラスを定義していることがわかりました。 WebLogicLogNotification。そのBest Practices状態:

すべてのJMX通知オブジェクトは、javax.management.Notificationオブジェクト型を拡張します。 JMXとWebLogic Serverは、javax.management.AttributeChangeNotificationなどの追加の通知オブジェクト型を定義します。追加のオブジェクトタイプには、さまざまなタイプのイベントに適した特別な情報セットが含まれています。

当社の通知は、我々は、通知に伝えたい情報のカスタムゲッターで私たち自身のサブクラスを定義考えると、そうWLSのように、標準のサブクラスのいずれかに適合しません。あるいは、javax.management.Notificationの基盤を守り、汎用のsetUserData(Object)を使って情報を添付する方が良いでしょうか?後者の場合、ObjectはCompositeDataのようなJMX型でなければならないと思います。消費者の視点から考えた方が良いでしょうか?

編集:コンシューマビューから、私はカスタムサブクラスの欠点は、アプリケーション/クラスパスにそれを含める必要があると思います。

答えて

4

ほとんどの場合、jmxでカスタムデータ型を使用することは悪い考えです。それは非常に制限です。開いているタイプに固執すれば、あなたのデータは任意のjmxクライアント(javaまたはそれ以外のもの)によって消費される可能性があります。

注:いつも "カスタムビーン" < - > "オープンタイプ"変換の何らかのヘルパークラスを提供できます。ヘルパークラスにアクセスできるクラスは、これらの簡易メソッド(例えば、ThreadInfo.from())を利用することができ、外部コードおよび非Javaコードは依然としてデータを消費することができる。

関連する問題