-
@Documented @Retention(value=RUNTIME) @Target(value=TYPE) public @interface MXBean
Annotation to mark an interface explicitly as being an MXBean interface, or as not being an MXBean interface. By default, an interface is an MXBean interface if its name ends with
MXBean
, as inSomethingMXBean
. The following interfaces are MXBean interfaces:public interface WhatsitMXBean {} @MXBean public interface Whatsit1Interface {} @MXBean(true) public interface Whatsit2Interface {}
The following interfaces are not MXBean interfaces:
public interface Whatsit3Interface{} @MXBean(false) public interface MisleadingMXBean {}
MXBean specification
The MXBean concept provides a simple way to code an MBean that only references a predefined set of types, the ones defined by
javax.management.openmbean
. In this way, you can be sure that your MBean will be usable by any client, including remote clients, without any requirement that the client have access to model-specific classes representing the types of your MBeans.The concepts are easier to understand by comparison with the Standard MBean concept. Here is how a managed object might be represented as a Standard MBean, and as an MXBean:
Standard MBean MXBean public interface MemoryPoolMBean { String getName(); MemoryUsage getUsage(); // ... }
public interface MemoryPoolMXBean { String getName(); MemoryUsage getUsage(); // ... }
As you can see, the definitions are very similar. The only difference is that the convention for naming the interface is to use
SomethingMXBean
for MXBeans, rather thanSomethingMBean
for Standard MBeans.In this managed object, there is an attribute called
Usage
of typeMemoryUsage
. The point of an attribute like this is that it gives a coherent snapshot of a set of data items. For example, it might include the current amount of used memory in the memory pool, and the current maximum of the memory pool. If these were separate items, obtained with separategetAttribute
calls, then we could get values seen at different times that were not consistent. We might get aused
value that was greater than themax
value.So, we might define
MemoryUsage
like this: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() {...} }
The definitions are the same in the two cases, except that with the MXBean,
MemoryUsage
no longer needs to be markedSerializable
(though it can be). On the other hand, we have added a@ConstructorProperties
annotation to link the constructor parameters to the corresponding getters. We will see more about this below.MemoryUsage
is a model-specific class. With Standard MBeans, a client of the MBean Server cannot access theUsage
attribute if it does not know the classMemoryUsage
. Suppose the client is a generic console based on JMX technology. Then the console would have to be configured with the model-specific classes of every application it might connect to. The problem is even worse for clients that are not written in the Java language. Then there may not be any way to tell the client what aMemoryUsage
looks like.This is where MXBeans differ from Standard MBeans. Although we define the management interface in almost exactly the same way, the MXBean framework converts model-specific classes into standard classes from the Java platform. Using arrays and the
CompositeData
andTabularData
classes from the standardjavax.management.openmbean
package, it is possible to build data structures of arbitrary complexity using only standard classes.This becomes clearer if we compare what the clients of the two models might look like:
Standard 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");For attributes with simple types like
String
, the code is the same. But for attributes with complex types, the Standard MBean code requires the client to know the model-specific classMemoryUsage
, while the MXBean code requires no non-standard classes.The client code shown here is slightly more complicated for the MXBean client. But, if the client does in fact know the model, here the interface
MemoryPoolMXBean
and the classMemoryUsage
, then it can construct a proxy. This is the recommended way to interact with managed objects when you know the model beforehand, regardless of whether you are using Standard MBeans or MXBeans:Standard 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();Implementing the MemoryPool object works similarly for both Standard MBeans and MXBeans.
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() {...} // ... }
Registering the MBean in the MBean Server works in the same way in both cases:
Standard MBean MXBean { MemoryPoolMBean pool = new MemoryPool(); mbeanServer.
registerMBean
(pool, objectName); }{ MemoryPoolMXBean pool = new MemoryPool(); mbeanServer.
registerMBean
(pool, objectName); }Definition of an MXBean
An MXBean is a kind of MBean. An MXBean object can be registered directly in the MBean Server, or it can be used as an argument to
StandardMBean
and the resultant MBean registered in the MBean Server.When an object is registered in the MBean Server using the
registerMBean
orcreateMBean
methods of theMBeanServer
interface, the object's class is examined to determine what type of MBean it is:- If the class implements the interface
DynamicMBean
then the MBean is a Dynamic MBean. Note that the classStandardMBean
implements this interface, so this case applies to a Standard MBean or MXBean created using the classStandardMBean
. - Otherwise, if the class matches the Standard MBean naming conventions, then the MBean is a Standard MBean.
- Otherwise, it may be an MXBean. The set of interfaces
implemented by the object is examined for interfaces that:
- have a class name
SMXBean
whereS
is any non-empty string, and do not have an annotation@MXBean(false)
; and/or - have an annotation
@MXBean(true)
or just@MXBean
.
MemoryPoolMXBean
. - have a class name
- If none of these conditions is met, the MBean is invalid and
the attempt to register it will generate
NotCompliantMBeanException
.
Every Java type that appears as the parameter or return type of a method in an MXBean interface must be convertible using the rules below. Additionally, parameters must be reconstructible as defined below.
An attempt to construct an MXBean that does not conform to the above rules will produce an exception.
Naming conventions
The same naming conventions are applied to the methods in an MXBean as in a Standard MBean:
- A method
T getN()
, whereT
is a Java type (notvoid
) andN
is a non-empty string, specifies that there is a readable attribute calledN
. The Java type and Open type of the attribute are determined by the mapping rules below. The methodfinal Class getClass()
inherited fromObject
is ignored when looking for getters. - A method
boolean isN()
specifies that there is a readable attribute calledN
with Java typeboolean
and Open typeSimpleType.Boolean
. - A method
void setN(T x)
specifies that there is a writeable attribute calledN
. The Java type and Open type of the attribute are determined by the mapping rules below. (Of course, the namex
of the parameter is irrelevant.) - Every other method specifies that there is an operation with the same name as the method. The Java type and Open type of the return value and of each parameter are determined by the mapping rules below.
The rules for
getN
andisN
collectively define the notion of a getter. The rule forsetN
defines the notion of a setter.It is an error for there to be two getters with the same name, or two setters with the same name. If there is a getter and a setter for the same name, then the type
T
in both must be the same. In this case the attribute is read/write. If there is only a getter or only a setter, the attribute is read-only or write-only respectively.Type mapping rules
An MXBean is a kind of Open MBean, as defined by the
javax.management.openmbean
package. This means that the types of attributes, operation parameters, and operation return values must all be describable using Open Types, that is the four standard subclasses ofOpenType
. MXBeans achieve this by mapping Java types into Open Types.For every Java type J, the MXBean mapping is described by the following information:
- The corresponding Open Type, opentype(J). This is
an instance of a subclass of
OpenType
. - The mapped Java type, opendata(J), which is always the same for any given opentype(J). This is a Java class.
- How a value is converted from type J to type opendata(J).
- How a value is converted from type opendata(J) to type J, if it can be.
For example, for the Java type
List<String>
:- The Open Type, opentype(
List<String>
), isArrayType
(1,
SimpleType.STRING
)
, representing a 1-dimensional array ofString
s. - The mapped Java type, opendata(
List<String>
), isString[]
. - A
List<String>
can be converted to aString[]
usingList.toArray(new String[0])
. - A
String[]
can be converted to aList<String>
usingArrays.asList
.
If no mapping rules exist to derive opentype(J) from J, then J cannot be the type of a method parameter or return value in an MXBean interface.
If there is a way to convert opendata(J) back to J then we say that J is reconstructible. All method parameters in an MXBean interface must be reconstructible, because when the MXBean framework is invoking a method it will need to convert those parameters from opendata(J) to J. In a proxy generated by
JMX.newMXBeanProxy
, it is the return values of the methods in the MXBean interface that must be reconstructible.Null values are allowed for all Java types and Open Types, except primitive Java types where they are not possible. When converting from type J to type opendata(J) or from type opendata(J) to type J, a null value is mapped to a null value.
The following table summarizes the type mapping rules.
Java type J opentype(J) opendata(J) int
,boolean
, etc
(the 8 primitive Java types)SimpleType.INTEGER
,
SimpleType.BOOLEAN
, etcInteger
,Boolean
, etc
(the corresponding boxed types)Integer
,ObjectName
, etc
(the types covered bySimpleType
)the corresponding SimpleType
J, the same type int[]
etc
(a one-dimensional array with
primitive element type)ArrayType.getPrimitiveArrayType(int[].class)
etcJ, the same type E []
(an array with non-primitive element type E; this includesint[][]
, where E isint[]
)ArrayType.getArrayType(
opentype(E))
opendata(E) []
List<
E>
Set<
E>
SortedSet<
E>
(see below)same as for E []
same as for E []
An enumeration E
(declared in Java asenum
E{...}
)SimpleType.STRING
String
Map<
K,V>
SortedMap<
K,V>
TabularType
(see below)TabularData
(see below)An MXBean interface SimpleType.OBJECTNAME
(see below)ObjectName
(see below)Any other type CompositeType
, if possible
(see below)CompositeData
The following sections give further details of these rules.
Mappings for primitive types
The 8 primitive Java types (
boolean
,byte
,short
,int
,long
,float
,double
,char
) are mapped to the corresponding boxed types fromjava.lang
, namelyBoolean
,Byte
, etc. The Open Type is the correspondingSimpleType
. Thus, opentype(long
) isSimpleType.LONG
, and opendata(long
) isjava.lang.Long
.An array of primitive type such as
long[]
can be represented directly as an Open Type. Thus, openType(long[]
) isArrayType.getPrimitiveArrayType(long[].class)
, and opendata(long[]
) islong[]
.In practice, the difference between a plain
int
andInteger
, etc, does not show up because operations in the JMX API are always on Java objects, not primitives. However, the difference does show up with arrays.Mappings for collections (List<E> etc)
A
List<
E>
orSet<
E>
, such asList<String>
orSet<ObjectName>
, is mapped in the same way as an array of the same element type, such asString[]
orObjectName[]
.A
SortedSet<
E>
is also mapped in the same way as an E[]
, but it is only convertible if E is a class or interface that implementsComparable
. Thus, aSortedSet<String>
orSortedSet<Integer>
is convertible, but aSortedSet<int[]>
orSortedSet<List<String>>
is not. The conversion of aSortedSet
instance will fail with anIllegalArgumentException
if it has a non-nullcomparator()
.A
List<
E>
is reconstructed as ajava.util.ArrayList<
E>
; aSet<
E>
as ajava.util.HashSet<
E>
; aSortedSet<
E>
as ajava.util.TreeSet<
E>
.Mappings for maps (Map<K,V> etc)
A
Map<
K,V>
orSortedMap<
K,V>
, for exampleMap<String,ObjectName>
, has Open TypeTabularType
and is mapped to aTabularData
. TheTabularType
has two items calledkey
andvalue
. The Open Type ofkey
is opentype(K), and the Open Type ofvalue
is opentype(V). The index of theTabularType
is the single itemkey
.For example, the
TabularType
for aMap<String,ObjectName>
might be constructed with code like this: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"});
The
typeName
here is determined by the type name rules detailed below.A
SortedMap<
K,V>
is mapped in the same way, but it is only convertible if K is a class or interface that implementsComparable
. Thus, aSortedMap<String,int[]>
is convertible, but aSortedMap<int[],String>
is not. The conversion of aSortedMap
instance will fail with anIllegalArgumentException
if it has a non-nullcomparator()
.A
Map<
K,V>
is reconstructed as ajava.util.HashMap<
K,V>
; aSortedMap<
K,V>
as ajava.util.TreeMap<
K,V>
.TabularData
is an interface. The concrete class that is used to represent aMap<
K,V>
as Open Data isTabularDataSupport
, or another class implementingTabularData
that serializes asTabularDataSupport
.Mappings for MXBean interfaces
An MXBean interface, or a type referenced within an MXBean interface, can reference another MXBean interface, J. Then opentype(J) is
SimpleType.OBJECTNAME
and opendata(J) isObjectName
.For example, suppose you have two MXBean interfaces like this:
public interface ProductMXBean { public ModuleMXBean[] getModules(); } public interface ModuleMXBean { public ProductMXBean getProduct(); }
The object implementing the
ModuleMXBean
interface returns from itsgetProduct
method an object implementing theProductMXBean
interface. TheModuleMXBean
object and the returnedProductMXBean
objects must both be registered as MXBeans in the same MBean Server.The method
ModuleMXBean.getProduct()
defines an attribute calledProduct
. The Open Type for this attribute isSimpleType.OBJECTNAME
, and the correspondingObjectName
value will be the name under which the referencedProductMXBean
is registered in the MBean Server.If you make an MXBean proxy for a
ModuleMXBean
and call itsgetProduct()
method, the proxy will map theObjectName
back into aProductMXBean
by making another MXBean proxy. More formally, when a proxy made withJMX.newMXBeanProxy(mbeanServerConnection, objectNameX, interfaceX)
needs to mapobjectNameY
back intointerfaceY
, another MXBean interface, it does so withJMX.newMXBeanProxy(mbeanServerConnection, objectNameY, interfaceY)
. The implementation may return a proxy that was previously created by a call toJMX.newMXBeanProxy
with the same parameters, or it may create a new proxy.The reverse mapping is illustrated by the following change to the
ModuleMXBean
interface:public interface ModuleMXBean { public ProductMXBean getProduct(); public void setProduct(ProductMXBean c); }
The presence of the
setProduct
method now means that theProduct
attribute is read/write. As before, the value of this attribute is anObjectName
. When the attribute is set, theObjectName
must be converted into theProductMXBean
object that thesetProduct
method expects. This object will be an MXBean proxy for the givenObjectName
in the same MBean Server.If you make an MXBean proxy for a
ModuleMXBean
and call itssetProduct
method, the proxy will map itsProductMXBean
argument back into anObjectName
. This will only work if the argument is in fact another proxy, for aProductMXBean
in the sameMBeanServerConnection
. The proxy can have been returned from another proxy (likeModuleMXBean.getProduct()
which returns a proxy for aProductMXBean
); or it can have been created byJMX.newMXBeanProxy
; or it can have been created usingProxy
with an invocation handler that isMBeanServerInvocationHandler
or a subclass.If the same MXBean were registered under two different
ObjectName
s, a reference to that MXBean from another MXBean would be ambiguous. Therefore, if an MXBean object is already registered in an MBean Server and an attempt is made to register it in the same MBean Server under another name, the result is anInstanceAlreadyExistsException
. Registering the same MBean object under more than one name is discouraged in general, notably because it does not work well for MBeans that areNotificationBroadcaster
s.Mappings for other types
Given a Java class or interface J that does not match the other rules in the table above, the MXBean framework will attempt to map it to a
CompositeType
as follows. The type name of thisCompositeType
is determined by the type name rules below.The class is examined for getters using the conventions above. (Getters must be public instance methods.) If there are no getters, or if any getter has a type that is not convertible, then J is not convertible.
If there is at least one getter and every getter has a convertible type, then opentype(J) is a
CompositeType
with one item for every getter. If the getter isT getName()
CompositeType
is calledname
and has type opentype(T). For example, if the item isString getOwner()
owner
and has Open TypeSimpleType.STRING
. If the getter isboolean isName()
CompositeType
is calledname
and has typeSimpleType.BOOLEAN
.Notice that the first character (or code point) is converted to lower case. This follows the Java Beans convention, which for historical reasons is different from the Standard MBean convention. In a Standard MBean or MXBean interface, a method
getOwner
defines an attribute calledOwner
, while in a Java Bean or mappedCompositeType
, a methodgetOwner
defines a property or item calledowner
.If two methods produce the same item name (for example,
getOwner
andisOwner
, orgetOwner
andgetowner
) then the type is not convertible.When the Open Type is
CompositeType
, the corresponding mapped Java type (opendata(J)) isCompositeData
. The mapping from an instance of J to aCompositeData
corresponding to theCompositeType
just described is done as follows. First, if J implements the interfaceCompositeDataView
, then that interface'stoCompositeData
method is called to do the conversion. Otherwise, theCompositeData
is constructed by calling the getter for each item and converting it to the corresponding Open Data type. Thus, a getter such asList<String> getNames()
will have been mapped to an item with name "
names
" and Open TypeArrayType(1, SimpleType.STRING)
. The conversion toCompositeData
will callgetNames()
and convert the resultantList<String>
into aString[]
for the item "names
".CompositeData
is an interface. The concrete class that is used to represent a type as Open Data isCompositeDataSupport
, or another class implementingCompositeData
that serializes asCompositeDataSupport
.Reconstructing an instance of Java type J from a
CompositeData
If opendata(J) is
CompositeData
for a Java type J, then either an instance of J can be reconstructed from aCompositeData
, or J is not reconstructible. If any item in theCompositeData
is not reconstructible, then J is not reconstructible either.For any given J, the following rules are consulted to determine how to reconstruct instances of J from
CompositeData
. The first applicable rule in the list is the one that will be used.If J has a method
public static
Jfrom(CompositeData cd)
then that method is called to reconstruct an instance of J.Otherwise, if J has at least one public constructor with a
ConstructorProperties
annotation, then one of those constructors (not necessarily always the same one) will be called to reconstruct an instance of J. Every such annotation must list as many strings as the constructor has parameters; each string must name a property corresponding to a getter of J; and the type of this getter must be the same as the corresponding constructor parameter. It is not an error for there to be getters that are not mentioned in theConstructorProperties
annotation (these may correspond to information that is not needed to reconstruct the object).An instance of J is reconstructed by calling a constructor with the appropriate reconstructed items from the
CompositeData
. The constructor to be called will be determined at runtime based on the items actually present in theCompositeData
, given that thisCompositeData
might come from an earlier version of J where not all the items were present. A constructor is applicable if all the properties named in itsConstructorProperties
annotation are present as items in theCompositeData
. If no constructor is applicable, then the attempt to reconstruct J fails.For any possible combination of properties, it must be the case that either (a) there are no applicable constructors, or (b) there is exactly one applicable constructor, or (c) one of the applicable constructors names a proper superset of the properties named by each other applicable constructor. (In other words, there should never be ambiguity over which constructor to choose.) If this condition is not true, then J is not reconstructible.
Otherwise, if J has a public no-arg constructor, and for every getter in J with type T and name N there is a corresponding setter with the same name and type, then an instance of J is constructed with the no-arg constructor and the setters are called with the reconstructed items from the
CompositeData
to restore the values. For example, if there is a method
public List<String> getNames()
then there must also be a method
public void setNames(List<String> names)
for this rule to apply.If the
CompositeData
came from an earlier version of J, some items might not be present. In this case, the corresponding setters will not be called.Otherwise, if J is an interface that has no methods other than getters, an instance of J is constructed using a
Proxy
with aCompositeDataInvocationHandler
backed by theCompositeData
being converted.Otherwise, J is not reconstructible.
Here are examples showing different ways to code a type
NamedNumber
that consists of anint
and aString
. In each case, theCompositeType
looks like this:CompositeType
( "NamedNumber", // typeName "NamedNumber", // description new String[] {"number", "name"}, // itemNames new String[] {"number", "name"}, // itemDescriptions new OpenType[] {SimpleType.INTEGER, SimpleType.STRING} // itemTypes );- Static
from
method: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; }
- Public constructor with
@ConstructorProperties
annotation: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; }
- Setter for every getter:
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; }
- Interface with only getters:
public interface NamedNumber { public int getNumber(); public String getName(); }
It is usually better for classes that simply represent a collection of data to be immutable. An instance of an immutable class cannot be changed after it has been constructed. Notice that
CompositeData
itself is immutable. Immutability has many advantages, notably with regard to thread-safety and security. So the approach using setters should generally be avoided if possible.Recursive types
Recursive (self-referential) types cannot be used in MXBean interfaces. This is a consequence of the immutability of
CompositeType
. For example, the following type could not be the type of an attribute, because it refers to itself:public interface Node { public String getName(); public int getPriority(); public Node getNext(); }
It is always possible to rewrite recursive types like this so they are no longer recursive. Doing so may require introducing new types. For example:
public interface NodeList { public List<Node> getNodes(); } public interface Node { public String getName(); public int getPriority(); }
MBeanInfo contents for an MXBean
An MXBean is a type of Open MBean. However, for compatibility reasons, its
MBeanInfo
is not anOpenMBeanInfo
. In particular, when the type of an attribute, parameter, or operation return value is a primitive type such asint
, or isvoid
(for a return type), then the attribute, parameter, or operation will be represented respectively by anMBeanAttributeInfo
,MBeanParameterInfo
, orMBeanOperationInfo
whosegetType()
orgetReturnType()
returns the primitive name ("int
" etc). This is so even though the mapping rules above specify that the opendata mapping is the wrapped type (Integer
etc).The array of public constructors returned by
MBeanInfo.getConstructors()
for an MXBean that is directly registered in the MBean Server will contain all of the public constructors of that MXBean. If the class of the MXBean is not public then its constructors are not considered public either. The list returned for an MXBean that is constructed using theStandardMBean
class is derived in the same way as for Standard MBeans. Regardless of how the MXBean was constructed, its constructor parameters are not subject to MXBean mapping rules and do not have a correspondingOpenType
.The array of notification types returned by
MBeanInfo.getNotifications()
for an MXBean that is directly registered in the MBean Server will be empty if the MXBean does not implement theNotificationBroadcaster
interface. Otherwise, it will be the result of callingNotificationBroadcaster.getNotificationInfo()
at the time the MXBean was registered. Even if the result of this method changes subsequently, the result ofMBeanInfo.getNotifications()
will not. The list returned for an MXBean that is constructed using theStandardMBean
orStandardEmitterMBean
class is derived in the same way as for Standard MBeans.The
Descriptor
for all of theMBeanAttributeInfo
,MBeanParameterInfo
, andMBeanOperationInfo
objects contained in theMBeanInfo
will have a fieldopenType
whose value is theOpenType
specified by the mapping rules above. So even whengetType()
is "int
",getDescriptor().getField("openType")
will beSimpleType.INTEGER
.The
Descriptor
for each of these objects will also have a fieldoriginalType
that is a string representing the Java type that appeared in the MXBean interface. The format of this string is described in the section Type Names below.The
Descriptor
for theMBeanInfo
will have a fieldmxbean
whose value is the string "true
".Type Names
Sometimes the unmapped type T of a method parameter or return value in an MXBean must be represented as a string. If T is a non-generic type, this string is the value returned by
Class.getName()
. Otherwise it is the value of genericstring(T), defined as follows:- If T is a non-generic non-array type,
genericstring(T) is the value returned by
Class.getName()
, for example"int"
or"java.lang.String"
. - If T is an array E[],
genericstring(T) is genericstring(E) followed
by
"[]"
. For example, genericstring(int[]
) is"int[]"
, and genericstring(List<String>[][]
) is"java.util.List<java.lang.String>[][]"
. - Otherwise, T is a parameterized type such as
List<String>
and genericstring(T) consists of the following: the fully-qualified name of the parameterized type as returned byClass.getName()
; a left angle bracket ("<"
); genericstring(A) where A is the first type parameter; if there is a second type parameter B then", "
(a comma and a single space) followed by genericstring(B); a right angle bracket (">"
).
Note that if a method returns
int[]
, this will be represented by the string"[I"
returned byClass.getName()
, but if a method returnsList<int[]>
, this will be represented by the string"java.util.List<int[]>"
.Exceptions
A problem with mapping from Java types to Open types is signaled with an
OpenDataException
. This can happen when an MXBean interface is being analyzed, for example if it references a type likejava.util.Random
that has no getters. Or it can happen when an instance is being converted (a return value from a method in an MXBean or a parameter to a method in an MXBean proxy), for example when converting fromSortedSet<String>
toString[]
if theSortedSet
has a non-nullComparator
.A problem with mapping to Java types from Open types is signaled with an
InvalidObjectException
. This can happen when an MXBean interface is being analyzed, for example if it references a type that is not reconstructible according to the rules above, in a context where a reconstructible type is required. Or it can happen when an instance is being converted (a parameter to a method in an MXBean or a return value from a method in an MXBean proxy), for example from a String to an Enum if there is no Enum constant with that name.Depending on the context, the
OpenDataException
orInvalidObjectException
may be wrapped in another exception such asRuntimeMBeanException
orUndeclaredThrowableException
. For every thrown exception, the condition C will be true: "e isOpenDataException
orInvalidObjectException
(as appropriate), or C is true of e.getCause()
".- Since:
- 1.6
- If the class implements the interface
-
-
Optional Element Summary
Optional Elements Modifier and Type Optional Element and Description boolean
value
True if the annotated interface is an MXBean interface.
-
Traduction non disponible
Les API Java ne sont pas encore traduites en français sur l'infobrol. Seule la version anglaise est disponible pour l'instant.
Version en cache
22/11/2024 03:05:18 Cette version de la page est en cache (à la date du 22/11/2024 03:05:18) afin d'accélérer le traitement. Vous pouvez activer le mode utilisateur dans le menu en haut pour afficher la dernère version de la page.Document créé le 11/06/2005, dernière modification le 04/03/2020
Source du document imprimé : https://www.gaudry.be/java-api-rf-javax/management/MXBean.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
Références
Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.