javax.management

Тип аннотации MXBean

@Documented
 @Retention(value=RUNTIME)
 @Target(value=TYPE)
public @interface MXBean

Аннотация, чтобы отметить интерфейс, явно как являющийся интерфейсом MXBean, или как не являющийся интерфейсом MXBean. По умолчанию интерфейс является интерфейсом MXBean, если его имя заканчивается MXBean, как в SomethingMXBean. Следующие интерфейсы являются интерфейсами MXBean:

    public interface WhatsitMXBean {}

    @MXBean
    public interface Whatsit1Interface {}

    @MXBean(true)
    public interface Whatsit2Interface {}
    

Следующие интерфейсы не являются интерфейсами MXBean:

    public interface Whatsit3Interface{}

    @MXBean(false)
    public interface MisleadingMXBean {}
    

Спецификация MXBean

Понятие MXBean обеспечивает простой способ кодировать MBean, который только ссылается на предопределенный набор типов, те определенные javax.management.openmbean. Таким образом можно убедиться, что Ваш MBean будет применим любым клиентом, включая удаленные клиенты, без любого требования, чтобы у клиента был доступ к специфичным для модели классам, представляющим типы Вашего MBeans.

Понятия легче понять в сравнении со Стандартным понятием MBean. Вот то, как управляемый объект мог бы быть представлен как Стандартный MBean, и как MXBean:

Стандартный MBean	MXBean
public interface MemoryPoolMBean { String getName(); MemoryUsage getUsage(); // ... }	public interface MemoryPoolMXBean { String getName(); MemoryUsage getUsage(); // ... }

Как можно видеть, определения очень подобны. Единственная разница - то, что соглашение для того, чтобы назвать интерфейс состоит в том, чтобы использовать SomethingMXBean для MXBeans, а не SomethingMBean для Стандартного MBeans.

В этом управляемом объекте есть вызванный атрибут Usage из типа MemoryUsage. Точка атрибута как это - то, что он дает когерентный снимок ряда элементов данных. Например, это могло бы включать текущее количество используемой памяти в пуле памяти, и текущий максимум пула памяти. Если они были отдельными элементами, полученными с отдельным getAttribute вызовы, тогда мы могли получить значения, замеченные в разное время, которые не были непротиворечивыми. Мы могли бы получить a used значение, которое было больше чем max значение.

Так, мы могли бы определить MemoryUsage как это:

Стандартный 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 (хотя это может быть). С другой стороны мы добавили a @ConstructorProperties аннотация, чтобы соединить параметры конструктора с соответствующими методами get. Мы будем видеть больше об этом ниже.

MemoryUsage специфичный для модели class. Со Стандартным MBeans клиент Сервера MBean не может получить доступ Usage припишите, если это не знает class MemoryUsage. Предположите, что клиент является универсальной консолью, основанной на технологии JMX. Затем консоль должна была бы быть сконфигурирована со специфичными для модели классами каждого приложения, с которым она могла бы соединиться. Проблема еще хуже для клиентов, которые не пишутся на языке Java. Затем, возможно, нет никакого способа сказать клиенту что a MemoryUsage похож.

Это - то, где MXBeans отличаются от Стандартного MBeans. Хотя мы определяем интерфейс управления в почти точно том же самом пути, платформа MXBean преобразовывает специфичные для модели классы в стандартные классы с платформы Java. Используя массивы и CompositeData и TabularData классы от стандарта javax.management.openmbean пакет, возможно создать структуры данных произвольной сложности, используя только стандартные классы.

Это становится более четким, если мы сравниваем то, на что могли бы быть похожими клиенты этих двух моделей:

Стандартный MBean	MXBean
String name = (String) mbeanServer.getAttribute(objectName, "Name"); MemoryUsage usage = (MemoryUsage) mbeanServer.getAttribute(objectName, "Usage"); long used = usage.getUsed();	String name = (String) mbeanServer.getAttribute(objectName, "Name"); CompositeData usage = (CompositeData) mbeanServer.getAttribute(objectName, "Usage"); long used = (Long) usage.get("used");

Для атрибутов с простыми типами как String, код является тем же самым. Но для атрибутов с составными типами, Стандартный код MBean требует, чтобы клиент знал специфичный для модели class MemoryUsage, в то время как код MXBean не требует никаких нестандартных классов.

Клиентский код, показанный здесь, немного более усложняется для клиента MXBean. Но, если клиент действительно фактически знает модель, здесь интерфейс MemoryPoolMXBean и class MemoryUsage, тогда это может создать прокси. Это - рекомендуемый способ взаимодействовать с управляемыми объектами, когда Вы знаете модель заранее, независимо от того, используете ли Вы Стандартный MBeans или MXBeans:

Стандартный MBean	MXBean
MemoryPoolMBean proxy = JMX.newMBeanProxy( mbeanServer, objectName, MemoryPoolMBean.class); String name = proxy.getName(); MemoryUsage usage = proxy.getUsage(); long used = usage.getUsed();	MemoryPoolMXBean proxy = JMX.newMXBeanProxy( mbeanServer, objectName, MemoryPoolMXBean.class); String name = proxy.getName(); MemoryUsage usage = proxy.getUsage(); long used = usage.getUsed();

Реализация объекта MemoryPool работает так же и на Стандартный MBeans и на MXBeans.

Стандартный 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 в Сервере MBean работает таким же образом в обоих случаях:

Стандартный MBean	MXBean
{ MemoryPoolMBean pool = new MemoryPool(); mbeanServer.registerMBean(pool, objectName); }	{ MemoryPoolMXBean pool = new MemoryPool(); mbeanServer.registerMBean(pool, objectName); }

Определение MXBean

MXBean является своего рода MBean. Объект MXBean может быть зарегистрирован непосредственно в Сервере MBean, или это может использоваться в качестве параметра StandardMBean и результирующий MBean зарегистрировался в Сервере MBean.

Когда объект регистрируется в Сервере MBean, используя registerMBean или createMBean методы MBeanServer интерфейс, class объекта исследуется, чтобы определить, какой MBean это:

• Если class реализует интерфейс DynamicMBean тогда MBean является Динамическим MBean. Отметьте что class StandardMBean реализации этот интерфейс, таким образом, этот случай применяется к Стандартному MBean или MXBean, создали использование class StandardMBean.
• Иначе, если class соответствует Стандартные соглашения о присвоении имен MBean, то MBean является Стандартный MBean.
• Иначе, это может быть MXBean. Набор интерфейсов, реализованных объектом, исследуется на интерфейсы что:
  • имейте имя class SMXBean где S любая непустая строка, и не имейте аннотации @MXBean(false); и/или
  • имейте аннотацию @MXBean(true) или только @MXBean.
  Если есть точно один такой интерфейс, или если есть один такой интерфейс, который является подынтерфейсом всего другие, то объект является MXBean. Рассматриваемый интерфейс является интерфейсом MXBean. В примере выше, интерфейс MXBean MemoryPoolMXBean.
• Если ни одно из этих условий не соблюдают, MBean недопустим и попытка зарегистрироваться, это генерирует NotCompliantMBeanException.

Каждый тип Java, который появляется как параметр или тип возврата метода в интерфейсе MXBean, должен быть конвертируемым использованием правил ниже. Дополнительно, параметры должны быть переконструируемыми как определено ниже.

Попытка создать MXBean, который не соответствует вышеупомянутым правилам, произведет исключение.

Соглашения о присвоении имен

Те же самые соглашения о присвоении имен применяются к методам в MXBean как в Стандартном MBean:

1. Метод T getN(), где T тип Java (нет void) и N непустая строка, определяет, что есть читаемый вызванный атрибут N. Тип Java и Открытый тип атрибута определяются отображающимися правилами ниже. Метод final Class getClass() наследованный от Object игнорируется, ища методов get.
2. Метод boolean isN() определяет, что есть читаемый вызванный атрибут N с типом Java boolean и Открытый тип SimpleType.Boolean.
3. Метод void setN(T x) определяет, что есть вызванный атрибут writeable N. Тип Java и Открытый тип атрибута определяются отображающимися правилами ниже. (Конечно, имя x из параметра не важно.)
4. Любой метод определяет, что есть работа с тем же самым именем как метод. Тип Java и Открытый тип возвращаемого значения и каждого параметра определяются отображающимися правилами ниже.

Правила для getN и isN все вместе определите понятие метода get. Правило для setN определяет понятие метода set.

Это - ошибка для там, чтобы быть двумя методами get с тем же самым именем, или двумя методами set с тем же самым именем. Если есть метод get и метод set для того же самого имени, то тип T в обоих должно быть то же самое. В этом случае атрибут является чтением-записью. Если есть только метод get или только метод set, атрибут только для чтения или только для записи соответственно.

Введите отображающиеся правила

MXBean является своего рода Открытым MBean, как определено javax.management.openmbean пакет. Это означает, что типы атрибутов, параметров работы, и возвращаемых значений работы должны все быть поддающимся описанию использованием Открытые Типы, который является четырьмя стандартными подклассами OpenType. MXBeans достигают этого, отображая типы Java в Открытые Типы.

Для каждого типа J Java отображение MXBean описывается следующей информацией:

• Соответствующий Открытый Тип, opentype (J). Это - экземпляр подкласса OpenType.
• Отображенный тип Java, opendata (J), который всегда является тем же самым для любого данного opentype (J). Это - Java class.
• Как значение преобразовывается от типа J до типа opendata (J).
• Как значение преобразовывается из типа opendata (J) к типу J, если это может быть.

Например, для типа Java List<String>:

• Открытый Тип, opentype (List<String>), ArrayType(1, SimpleType.STRING), представление 1-мерного массива Strings.
• Отображенный тип Java, opendata (List<String>), String[].
• A List<String> может быть преобразован в a String[] использование List.toArray(new String[0]).
• A String[] может быть преобразован в a List<String> использование Arrays.asList.

Если никакие правила отображения не существуют, чтобы получить opentype (J) из J, то J не может быть типом параметра метода или возвращаемого значения в интерфейсе MXBean.

Если есть способ преобразовать opendata (J) назад к J тогда, мы говорим, что J переконструируем. Все параметры метода в интерфейсе MXBean должны быть переконструируемыми, потому что, когда платформа MXBean вызывает метод, она должна будет преобразовать те параметры из opendata (J) к J. В прокси, сгенерированном JMX.newMXBeanProxy, это - возвращаемые значения методов в интерфейсе MXBean, который должен быть переконструируемым.

Нулевые значения позволяются для всех типов Java и Открытых Типов, кроме примитивных типов Java, где они не возможны. Преобразовывая от типа J до типа opendata (J) или от типа opendata (J) к типу J, нулевое значение отображается на нулевое значение.

Следующая таблица суммирует правила отображения типа.

Тип J Java	opentype (J)	opendata (J)
int, boolean, и т.д. (8 примитивных типов Java)	SimpleType.INTEGER, SimpleType.BOOLEAN, и т.д.	Integer, Boolean, и т.д. (соответствующие упакованные типы)
Integer, ObjectName, и т.д. (типы, покрытые SimpleType)	соответствие SimpleType	J, тот же самый тип
int[] и т.д. (одномерный массив с примитивный тип элемента)	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, и т.д. Открытый Тип является соответствием SimpleType. Таким образом, opentype (long) SimpleType.LONG, и opendata (long) java.lang.Long.

Массив типа примитива такой как long[] может быть представлен непосредственно как Открытый Тип. Таким образом, openType (long[]) ArrayType.getPrimitiveArrayType(long[].class), и opendata (long[]) long[].

Практически, различие между плоскостью int и Integer, и т.д., не обнаруживается, потому что операции в API JMX всегда находятся на объектах Java, не примитивах. Однако, различие действительно обнаруживается с массивами.

Отображения для наборов (List<E> и т.д.)

A List<E> или Set<E>, такой как List<String> или Set<ObjectName>, отображается таким же образом как массив того же самого типа элемента, такой как String[] или ObjectName[].

A SortedSet<E> также отображается таким же образом как E[], но это только конвертируемо, если E является class, или взаимодействуйте через интерфейс, который реализует Comparable. Таким образом, a SortedSet<String> или SortedSet<Integer> конвертируемо, но a SortedSet<int[]> или SortedSet<List<String>> не. Преобразование a SortedSet экземпляр перестанет работать с IllegalArgumentException если у этого есть ненуль comparator().

A List<E> восстанавливается как a java.util.ArrayList<E>; a Set<E> как a java.util.HashSet<E>; a SortedSet<E> как a java.util.TreeSet<E>.

Отображения для карт (Map<K, V> и т.д.)

A Map<K, V> или SortedMap<K, V>, например Map<String,ObjectName>, имеет Открытый Тип TabularType и отображается на a TabularData. TabularType имеет два вызванные элемента key и value. Открытый Тип key opentype (K), и Открытый Тип value opentype (V). Индексирование TabularType единственный элемент key.

Например, TabularType для a Map<String,ObjectName> мог бы быть создан с кодом как это:

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 здесь определяется правилами имени типа, детализированными ниже.

A SortedMap<K, V> отображается таким же образом, но это только конвертируемо, если K является class, или взаимодействуйте через интерфейс, который реализует Comparable. Таким образом, a SortedMap<String,int[]> конвертируемо, но a SortedMap<int[],String> не. Преобразование a SortedMap экземпляр перестанет работать с IllegalArgumentException если у этого есть ненуль comparator().

A Map<K, V> восстанавливается как a java.util.HashMap<K, V>; a SortedMap<K, V> как a java.util.TreeMap<K, V>.

TabularData интерфейс. Конкретный class, который используется, чтобы представить a Map<K, V> поскольку Открытые Данные TabularDataSupport, или другая реализация class TabularData это сериализирует как TabularDataSupport.

Отображения для интерфейсов MXBean

Интерфейс MXBean, или тип, на который ссылаются в пределах интерфейса MXBean, может сослаться на другой интерфейс MXBean, J. Затем opentype (J) SimpleType.OBJECTNAME и opendata (J) ObjectName.

Например, предположите, что у Вас есть два интерфейса MXBean как это:

public interface ProductMXBean {
    public ModuleMXBean[] getModules();
}

public interface ModuleMXBean {
    public ProductMXBean getProduct();
}
    

Объект, реализовывая ModuleMXBean соедините интерфейсом с возвратами из getProduct метод объект, реализовывая ProductMXBean интерфейс. ModuleMXBean возразите и возвращенный ProductMXBean объекты должны оба быть зарегистрированы как MXBeans в том же самом Сервере MBean.

Метод ModuleMXBean.getProduct() определяет вызванный атрибут Product. Открытый Тип для этого атрибута SimpleType.OBJECTNAME, и соответствие ObjectName значение будет именем под который ссылаемый ProductMXBean регистрируется в Сервере MBean.

Если Вы заставляете MXBean проксировать для a ModuleMXBean и вызовите getProduct() метод, прокси отобразится ObjectName назад в a ProductMXBean делая другой прокси MXBean. Более формально, когда прокси, сделанный с JMX.newMXBeanProxy(mbeanServerConnection, objectNameX, interfaceX) потребности отобразиться objectNameY назад в interfaceY, другой интерфейс MXBean, это делает так с JMX.newMXBeanProxy(mbeanServerConnection, objectNameY, interfaceY). Реализация может возвратить прокси, который ранее создавался звонком JMX.newMXBeanProxy с теми же самыми параметрами, или это может создать новый прокси.

Обратное отображение иллюстрируется следующим изменением к ModuleMXBean интерфейс:

public interface ModuleMXBean {
    public ProductMXBean getProduct();
    public void setProduct(ProductMXBean c);
}
    

Присутствие setProduct метод теперь означает что Product атрибут является чтением-записью. Как прежде, значение этого атрибута ObjectName. Когда атрибут устанавливается, ObjectName должен быть преобразован в ProductMXBean возразите что setProduct метод ожидает. Этот объект будет прокси MXBean для данного ObjectName в том же самом Сервере MBean.

Если Вы заставляете MXBean проксировать для a ModuleMXBean и вызовите setProduct метод, прокси отобразит ProductMXBean параметр назад в ObjectName. Это будет только работать, если параметром будет фактически другой прокси для a ProductMXBean в том же самом MBeanServerConnection. Прокси мог быть возвращен из другого прокси (как ModuleMXBean.getProduct() который возвращает прокси для a ProductMXBean); или это могло быть создано JMX.newMXBeanProxy; или это могло быть создано, используя Proxy с обработчиком вызова, который является MBeanServerInvocationHandler или подкласс.

Если те же самые MXBean были зарегистрированы под два отличающийся ObjectNames, ссылка на это MXBean от другого MXBean был бы неоднозначен. Поэтому, если объект MXBean уже регистрируется в Сервере MBean, и попытка предпринимается, чтобы зарегистрировать его в том же самом Сервере MBean под другим именем, результат InstanceAlreadyExistsException. Регистрации того же самого объекта MBean больше чем под одним именем обескураживают вообще, особенно потому что это не работает хорошо на MBeans, которые являются NotificationBroadcasters.

Отображения для других типов

Учитывая Java class или интерфейс J, который не соответствует другие правила в таблице выше, платформа MXBean попытается отобразить ее на a CompositeType следующим образом. Имя типа этого CompositeType определяется правилами имени типа ниже.

class исследуется на методов get, использующих соглашения выше. (Методы get должны быть общедоступными методами экземпляра.), Если нет никаких методов get, или если у какого-либо метода get есть тип, который не конвертируем, тогда J не конвертируем.

Если есть по крайней мере один метод get, и у каждого метода get есть конвертируемый тип, то opentype (J) является a CompositeType с одним элементом для каждого метода get. Если метод get

T getName()

тогда элемент в CompositeType вызывается name и имеет тип opentype (T). Например, если элемент

String getOwner()

тогда элемент вызывают owner и имеет Открытый Тип SimpleType.STRING. Если метод get

boolean isName()

тогда элемент в CompositeType вызывается name и имеет тип SimpleType.BOOLEAN.

Заметьте, что первый символ (или кодовая точка) преобразовывается в нижний регистр. Это следует за Бобовым соглашением Java, которое по историческим причинам отличается от Стандартного соглашения MBean. В Стандартном MBean или интерфейсе MXBean, методе getOwner определяет вызванный атрибут Owner, в то время как в Бобе Java или отображенный CompositeType, метод getOwner определяет свойство или вызванный элемент owner.

Если два метода производят то же самое название товара (например, getOwner и isOwner, или getOwner и getowner) тогда тип не конвертируем.

Когда Открытый Тип CompositeType, соответствующий отображенный тип Java (opendata (J)) CompositeData. Отображение от экземпляра J к a CompositeData соответствие CompositeType только описанный делается следующим образом. Во-первых, если J реализует интерфейс CompositeDataView, тогда тот интерфейс toCompositeData метод вызывают, чтобы сделать преобразование. Иначе, CompositeData создается, вызывая метода get для каждого элемента и преобразовывая это в соответствующий Открытый Тип данных. Таким образом, метод get такой как

List<String> getNames()

будет отображен на элемент с именем"names"и Открытый Тип ArrayType(1, SimpleType.STRING). Преобразование в CompositeData вызовет getNames() и преобразуйте результант List<String> в a String[] для элемента"names".

CompositeData интерфейс. Конкретный class, который используется, чтобы представить тип как Открытые Данные, CompositeDataSupport, или другая реализация class CompositeData это сериализирует как CompositeDataSupport.

Восстановление экземпляра типа J Java от a CompositeData

Если opendata (J) CompositeData для типа J Java тогда любой экземпляр J может быть восстановлен от a CompositeData, или J не переконструируем. Если любой элемент в CompositeData не переконструируемо, тогда J не переконструируем также.

Для любого данного J, со следующими правилами консультируются, чтобы определить, как восстановить экземпляры J от CompositeData. Первое применимое правило в списке является тем, которое будет использоваться.

1. Если у J есть метод
   public static J from(CompositeData cd)
   тогда тот метод вызывают, чтобы восстановить экземпляр J.

2. Иначе, если у J есть по крайней мере один общедоступный конструктор с a ConstructorProperties аннотация, тогда одного из тех конструкторов (не обязательно всегда тот же самый) вызовут, чтобы восстановить экземпляр J. Каждая такая аннотация должна перечислить так много строк, как у конструктора есть параметры; каждая строка должна назвать свойство, соответствующее методу get J; и тип этого метода get должен быть тем же самым как соответствующим параметром конструктора. Это не ошибка для там, чтобы быть методами get, которые не упоминаются в ConstructorProperties аннотация (они могут соответствовать информации, которая не необходима, чтобы восстановить объект).

   Экземпляр J восстанавливается, вызывая конструктора с соответствующими восстановленными элементами от CompositeData. Конструктор, которого вызовут, будет определен во времени выполнения, основанном на элементах, фактически существующих в CompositeData, учитывая, что это CompositeData мог бы прибыть из более ранней версии J, где не все элементы присутствовали. Конструктор применим если все свойства, названные в ConstructorProperties аннотация присутствует как элементы в CompositeData. Если никакой конструктор не применим, то попытка восстановить сбои J.

   Для любой возможной комбинации свойств это должно иметь место, что или (a) там не являются никакими применимыми конструкторами, или (b), там точно один применимый конструктор, или (c), один из применимых конструкторов называет надлежащее надмножество свойств названным друг другом применимым конструктором. (Другими словами никогда не должно быть неоднозначности по который конструктор выбрать.), Если это условие не является истиной, то J не переконструируем.

3. Иначе, если у J есть общедоступный конструктор без аргументов, и для каждого метода get в J с типом T и именем N, там соответствующий метод set с тем же самым именем и типом, то экземпляр J создается с конструктором без аргументов, и методы set вызывают с восстановленными элементами от CompositeData восстановить значения. Например, если есть метод
   public List<String> getNames()
   тогда должен также быть метод
   public void setNames(List<String> names)
   для этого правила применяться.

   Если CompositeData прибыл из более ранней версии J, некоторые элементы не могли бы присутствовать. В этом случае соответствующие методы set не вызовут.

4. Иначе, если J является интерфейсом, у которого нет никаких методов кроме методов get, экземпляр J создается, используя a Proxy с a CompositeDataInvocationHandler поддержанный CompositeData быть преобразованным.

5. Иначе, J не переконструируем.

Правило 2 не применимо к Профилям подмножества Java SE, которые не включают java.beans пакет. Предназначаясь для времени выполнения, которое не включает java.beans пакет, и где есть несоответствие между временем компиляции и средой выполнения, посредством чего J компилируется с общедоступным конструктором и ConstructorProperties аннотация, тогда J не переконструируема, если другое правило не применяется.

Вот примеры, показывая различные способы кодировать тип NamedNumber это состоит из int и a String. В каждом случае, CompositeType похож на это:

CompositeType(
    "NamedNumber",                      // typeName
    "NamedNumber",                      // description
    new String[] {"number", "name"},    // itemNames
    new String[] {"number", "name"},    // itemDescriptions
    new OpenType[] {SimpleType.INTEGER,
                    SimpleType.STRING}  // itemTypes
);
      

1. Статичный 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;
   }
             

2. Общедоступный конструктор с @ConstructorProperties аннотация:

   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;
   }
             

3. Метод set для каждого метода get:

   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;
   }
             

4. Интерфейс с только методами get:

   public interface NamedNumber {
       public int getNumber();
       public String getName();
   }
             

Это обычно лучше для классов, которые просто представляют набор данных, чтобы быть неизменными. Экземпляр неизменного class не может быть изменен после того, как он был создан. Заметьте это CompositeData непосредственно является неизменным. У неизменности есть много преимуществ, особенно относительно потокобезопасности и безопасности. Таким образом, подхода, используя методы set нужно обычно избежать если возможный.

Рекурсивные типы

Рекурсивные (самосправочные) типы не могут использоваться в интерфейсах 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();
}

Содержание MBeanInfo для MXBean

MXBean является типом Открытого MBean. Однако, по причинам совместимости, MBeanInfo не OpenMBeanInfo. В частности когда тип атрибута, параметра, или возвращаемого значения работы является типом примитива такой как int, или void (для типа возврата), тогда атрибут, параметр, или работа будут представлены соответственно MBeanAttributeInfo, MBeanParameterInfo, или MBeanOperationInfo чей getType() или getReturnType() возвращает примитивное имя ("int"и т.д.). Это так даже при том, что отображающиеся правила выше определяют, что отображение opendata является обернутым типом (Integer и т.д.).

Массив общедоступных конструкторов, возвращенных MBeanInfo.getConstructors() для MXBean, который непосредственно регистрируется в Сервере MBean, будет содержать всех общедоступных конструкторов этого MXBean. Если class MXBean не общедоступен тогда, его конструкторов не считают общедоступными также. Список, возвращенный для MXBean, который создается, используя StandardMBean class получается таким же образом что касается Стандартного MBeans. Независимо от того, как был создан MXBean, его параметры конструктора не подвергаются MXBean отображающиеся правила и не имеют соответствия OpenType.

Массив типов уведомления, возвращенных MBeanInfo.getNotifications() для MXBean, который непосредственно регистрируется в Сервере MBean, будет пусто, если MXBean не реализует NotificationBroadcaster интерфейс. Иначе, это будет результат вызова NotificationBroadcaster.getNotificationInfo() в то время, когда MXBean был зарегистрирован. Даже если результат этого метода изменяется впоследствии, результат MBeanInfo.getNotifications() не будет. Список, возвращенный для MXBean, который создается, используя StandardMBean или StandardEmitterMBean class получается таким же образом что касается Стандартного MBeans.

Descriptor для всего из MBeanAttributeInfo, MBeanParameterInfo, и MBeanOperationInfo объекты, содержавшиеся в MBeanInfo будет иметь поле openType чье значение OpenType определенный отображающимися правилами выше. Так даже когда getType() "int", getDescriptor().getField("openType") будет SimpleType.INTEGER.

Descriptor поскольку у каждого из этих объектов также будет поле originalType это - строка, представляющая тип Java, который появился в интерфейсе MXBean. Формат этой строки описывается в Именах типов раздела ниже.

Descriptor для MBeanInfo будет иметь поле mxbean чье значение является строкой"true".

Имена типов

Иногда неотображенный тип T параметра метода или возвращаемого значения в MXBean должен быть представлен как строка. Если T является неуниверсальным типом, эта строка является значением, возвращенным Class.getName(). Иначе это - значение genericstring (T), определенный следующим образом:

• Если T является неуниверсальным типом немассива, genericstring (T) является значением, возвращенным Class.getName(), например "int" или "java.lang.String".
• Если T является массивом E [], genericstring (T) является genericstring (E) сопровождаемый "[]". Например, genericstring (int[]) "int[]", и genericstring (List<String>[][]) "java.util.List<java.lang.String>[][]".
• Иначе, T является параметризованным типом такой как List<String> и genericstring (T) состоит из следующего: полностью определенное имя параметризованного типа как возвращено Class.getName(); левая угловая скобка ("<"); genericstring (A), где A является первым параметром типа; если есть второй параметр типа B тогда ", " (запятая и одинарный интервал) сопровождаемый genericstring (B); правая угловая скобка (">").

Отметьте это, если метод возвращается int[], это будет представлено строкой "[I" возвращенный Class.getName(), но если метод возвращается List<int[]>, это будет представлено строкой "java.util.List<int[]>".

Исключения

Проблема с отображением от типов Java, чтобы Открыть типы сообщается с OpenDataException. Это может произойти, когда интерфейс MXBean анализируется, например если он ссылается на тип как java.util.Random у этого нет никаких методов get. Или это может произойти, когда экземпляр преобразовывается (возвращаемое значение из метода в MXBean или параметре к методу в прокси MXBean), например преобразовывая из SortedSet<String> к String[] если SortedSet имеет ненуль Comparator.

Проблема с отображением на типы Java от Открытых типов сообщается с InvalidObjectException. Это может произойти, когда интерфейс MXBean анализируется, например если он ссылается на тип, который не переконструируем согласно правилам выше в контексте, где переконструируемый тип требуется. Или это может произойти, когда экземпляр преобразовывается (параметр в метод в MXBean или возвращаемом значении от метода в прокси MXBean), например от Строки до Перечисления, если нет никакой Перечислимой константы с тем именем.

В зависимости от контекста, OpenDataException или InvalidObjectException может быть обернут в другое исключение такой как RuntimeMBeanException или UndeclaredThrowableException. Для каждого выданного исключения условие C будет истиной: "e OpenDataException или InvalidObjectException (как соответствующий), или C верен для e.getCause()".

С тех пор:

1.6

Дополнительная Сводка Элемента

Дополнительные Элементы

Модификатор и Тип	Дополнительный Элемент и Описание
boolean	значение Истина, если аннотируемый интерфейс является интерфейсом MXBean.

Деталь элемента

значение

public abstract boolean value

Истина, если аннотируемый интерфейс является интерфейсом MXBean.

Возвраты:

истина, если аннотируемый интерфейс является интерфейсом MXBean.

Значение по умолчанию:

истина