JavaTM Platform
Standard Ed. 6

javax.management
주석형 MXBean



@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 스펙

MXBean 의 개념을 사용하면(자),javax.management.openmbean 에 의해 정의된, 정의 끝난 형태 세트만을 참조하는 MBean 를 간단하게 코딩 할 수 있습니다. 이것에 의해, 원격 클라이언트를 포함한 임의의 클라이언트가, MBean 의 형태를 나타내는 「모델 고유 클래스」에 액세스 하지 않아도, MBean 를 확실히 사용할 수 있게 됩니다.

이 개념은, Standard MBean 의 개념과 비교해, 이해하기 쉬운 것입니다. 여기에서는, 관리 대상 객체를 Standard MBean 및 MXBean 로서 표현하는 방법에 대해 설명합니다.

Standard MBeanMXBean
public interface MemoryPoolMBean {
    String getName();
    MemoryUsage getUsage();
    // ...
}
          
public interface MemoryPoolMXBean {
    String getName();
    MemoryUsage getUsage();
    // ...
}
          

상기의 기술로부터, 정의는 매우 유사하고 있는 것을 알 수 있습니다. 유일한 차이점은, 인터페이스의 명명 규칙으로서 Standard MBean 에서는 SomethingMBean 를 사용하는데 대해, MXBean 에서는 SomethingMXBean 를 사용한다고 하는 점입니다.

이 관리 대상 객체에서는,MemoryUsage 형의 Usage 라는 이름의 속성이 있습니다. 이런 종류의 속성의 특징은, 데이터 항목 세트의 일관한 snapshot를 제공하는 점입니다. 예를 들어, 메모리 풀내의 현재의 사용이 끝난 메모리 용량이나, 현재의 메모리 풀의 최대치를 포함할 수가 있습니다. 이것들이 다른 항목이 되어 있으면(자),getAttribute 를 개별적으로 호출해 항목을 취득하기 위해(때문에), 다양한 시점의 일관성이 없는 값을 취득할 가능성이 있습니다. max 치보다 큰 used 치를 취득할 가능성도 있습니다.

이 때문에, 다음과 같이 MemoryUsage 를 정의할 수 있습니다.

Standard MBeanMXBean
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 에서는 MemoryUsageSerializable 의 마크를 붙일 필요가 없는 것을 제외하면, 어느 쪽의 경우도 정의는 같습니다 (다만,Serializable 의 마크를 붙이는 것은 가능). 한편, MXBean 에는, 생성자 파라미터를 대응하는 취득 메소드에 링크하기 위한 ,@ConstructorProperties 주석이 추가되고 있습니다. 이 점에 대해서는, 나중에 자세하게 설명합니다.

MemoryUsage 는, 「모델 고유 클래스」입니다. Standard MBean 에서는,MemoryUsage 클래스가 불명한 경우, MBean Server 의 클라이언트는 Usage 속성에 액세스 할 수 없습니다. 클라이언트가, JMX 기술에 근거하는 총칭 콘솔인 경우를 생각해 봅시다. 이 경우, 콘솔은, 접속처의 각 어플리케이션의 모델 고유 클래스를 사용해 설정할 필요가 있습니다. Java 언어로 기술되어 있지 않은 클라이언트의 경우, 문제는 한층 어려워집니다. 이 경우,MemoryUsage 의 내용에 대해 클라이언트에 알릴 방법이 없을 가능성이 있습니다.

이러한 경우에, MXBean 는 Standard MBean 와 다릅니다. 관리 인터페이스의 정의 방법은 거의 같습니다만, MXBean 시스템에서는, 모델 고유 클래스가 Java 플랫폼의 표준 클래스에 변환됩니다. 배열 및 표준 javax.management.openmbean 패키지 CompositeData 클래스와 TabularData 클래스를 사용하는 것으로, 임의의 복잡함의 데이터 구조를 표준 클래스만을 사용해 구축할 수 있습니다.

이 점은, 2 개의 모델의 클라이언트를 비교하는 것으로보다 명확하게 됩니다.

Standard MBeanMXBean
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 등이 단순한 형태의 속성의 경우, 코드는 같습니다. 다만, 복잡한 형태의 속성의 경우, Standard MBean 의 코드에서는 클라이언트가 모델 고유 클래스 MemoryUsage 를 인식할 필요가 있는데 대해, MXBean 의 코드에서는 비표준 클래스는 필요 없습니다.

여기에 나타내는 클라이언트 코드에서는, MXBean 클라이언트가 얼마인가 복잡하게 되어 있습니다. 다만, 클라이언트가 모델 (여기에서는,MemoryPoolMXBean 인터페이스와 MemoryUsage 클래스)을 실제로 인식하고 있는 경우는, 「프록시」의 구축이 가능합니다. 모델이 사전에 아는 경우에는, Standard MBean 를 사용할까 MXBean 를 사용할까에 관계없이, 이 방법으로 관리 대상 객체와의 교환을 실시하는 것을 추천합니다.

Standard MBeanMXBean
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 객체의 구현의 동작은, Standard MBean 에서도 MXBean 에서도 같습니다.

Standard MBeanMXBean
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 MBeanMXBean
{
MemoryPoolMBean pool = new MemoryPool();
mbeanServer. registerMBean (pool, objectName);
}
          
{
MemoryPoolMXBean pool = new MemoryPool();
mbeanServer. registerMBean (pool, objectName);
}
          

MXBean 의 정의

MXBean 는, MBean 의 일종입니다. MXBean 객체는, MBean Server 에 직접 등록하는 일도,StandardMBean 의 인수로서 사용해, 결과의 MBean 를 MBean Server 에 등록할 수도 있습니다.

MBeanServer 인터페이스의 registerMBeancreateMBean 메소드를 사용해 객체를 MBean Server 에 등록하면(자), MBean 의 형태를 판별하기 위해서 객체의 클래스가 검사됩니다.

MXBean 인터페이스내에서 메소드의 파라미터 또는 반환값의 형태로서 나타나는 모든 Java 형이, 다음의 룰에 따라 「변환 가능」이 아니면 안됩니다. 또, 파라미터가 이하의 정의에 따라 재구축 가능하지 않으면 안됩니다.

상기의 룰에 준거하지 않는 MXBean 를 구축하려고 하면(자), 예외가 throw 됩니다.

명명 규칙

MXBean 내의 메소드에는, Standard MBean 내의 메소드와 같은 명명 규칙이 적용됩니다.

  1. T getN() 메소드 (Tvoid 가 아닌 Java 형,N 는 빈 상태(empty)이 아닌 캐릭터 라인)는,N 라는 이름의 읽어내 가능한 속성이 존재하는 것을 나타냅니다. 속성의 Java 형 및 공개형은, 다음의 매핑 룰에 따라 결정됩니다. Object 로부터 상속한 final Class getClass() 메소드는, 취득 메소드의 검색시에는 무시됩니다.
  2. boolean isN() 메소드는, Java 형 boolean 및 공개형 SimpleType.Boolean 의 읽기 가능 속성 N 가 존재하는 것을 나타냅니다.
  3. void setN(T x) 메소드는, 기입 가능 속성 N 가 존재하는 것을 나타냅니다. 속성의 Java 형 및 공개형은, 다음의 매핑 룰에 따라 결정됩니다. 파라미터의 이름 x 는 관계 없습니다.
  4. 다른 모든 메소드는, 메소드와 같은 이름의 연산이 존재하는 것을 나타냅니다. 반환값 및 각 파라미터의 Java 형 및 공개형은, 다음의 매핑 룰에 따라 결정됩니다.

getNisN 의 룰에 의해, 「취득 메소드」의 개념이 정리해 정의됩니다. setN 의 룰에 의해, 「설정 메소드」의 개념이 정의됩니다.

동명의 취득 메소드가 2 개 존재하거나 동명의 설정 메소드가 2 개 존재하면(자) 에러가 됩니다. 동명의 취득 메소드와 설정 메소드가 존재하는 경우는, 양쪽 모두의 T 형을 같게 합니다. 이 경우, 속성은 읽어내/기입 속성이 됩니다. 취득 메소드와 설정 메소드의 어느쪽이든 한편이 1 개만 존재하는 경우, 속성은 각각 읽어내 전용 또는 기입해 전용이 됩니다.

형태 매핑 룰

javax.management.openmbean 패키지로 정의되고 있도록(듯이), MXBean 는 Open MBean 의 일종입니다. 이것은, 속성, 연산 파라미터, 및 연산의 반환값이 모두, 「공개형」 (즉 OpenType 의 4 개의 표준 서브 클래스)을 사용해 기술 가능하지 않으면 안 되는 것을 의미합니다. MXBean 에서는, Java 형을 공개형에 매핑 하는 것으로 이것을 실현합니다.

모든 Java 형 J 로, MXBean 매핑의 기술에 다음의 정보가 사용됩니다.

예를 들어, Java 형 List<String> 에 대해 생각해 봅시다.

J 로부터 opentype(J) 를 파생시키는 매핑 룰이 존재하지 않는 경우,J 를 MXBean 인터페이스내의 메소드 파라미터 또는 반환값의 형태로 할 수 없습니다.

opendata(J)J 에 재변환하는 방법이 있는 경우,J 는 「재구축 가능」이다고 합니다. MXBean 인터페이스내의 모든 메소드 파라미터는, 재구축 가능하지 않으면 안됩니다. 이것은, MXBean 시스템가 메소드를 호출할 때에, 이러한 파라미터를 opendata(J) 로부터 J 로 변환할 필요가 있기 (위해)때문에입니다. JMX.newMXBeanProxy 에 의해 생성된 프록시에서는, 이것은, 재구축 가능하지 않으면 안 되는 MXBean 인터페이스내의 메소드의 반환값입니다.

null 치를 사용할 수 없는 프리미티브(primitive) Java 형을 제외한, 모든 Java 형과 공개형으로, null 치가 허가됩니다. J 형을 opendata(J) 형으로 변환하거나opendata(J) 형을 J 형으로 변환하는 경우는, null 치와 null 치가 매핑 됩니다.

다음의 겉(표)에, 형태 매핑 룰의 개요를 나타냅니다.

Java 형 J opentype(J) opendata(J)
int,boolean
(8 개의 프리미티브(primitive) Java 형)
SimpleType.INTEGER,
SimpleType.BOOLEAN
Integer,Boolean
(대응하는 boxed 형)
Integer,ObjectName
(SimpleType 의 적용 범위내의 형태)
대응하는 SimpleType J, 같은 형태
int[]
(프리미티브(primitive) 요소형의
1 차원 배열)
ArrayType.getPrimitiveArrayType(int[]. class) J, 같은 형태
E[]
(비프리미티브(primitive) 요소형 E 의 배열,int[][] 를 포함한다. Eint[])
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 개의 프리미티브(primitive) 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 내의 연산은 프리미티브(primitive)이지 않고 항상 Java 객체상에서 실행되기 (위해)때문에, 실제로는, 프레인인 intInteger 의 차이등이 명확하게 될 것은 없습니다. 다만, 배열로 차이가 밝혀집니다.

컬렉션의 매핑 (List<E> 등)

List<E>Set<E> (List<String> 이나 Set<ObjectName> 등)의 매핑 방법은, 같은 요소형의 배열 (String[]ObjectName[] 등)과 같습니다.

SortedSet<E>E[] 와 같은 방법으로 매핑 됩니다. 다만, 이것이 변환 가능한 것은,EComparable 를 구현하는 클래스 또는 인터페이스인 경우만입니다. 이 때문에,SortedSet<String>SortedSet<Integer> 는 변환 가능합니다만,SortedSet<int[]>SortedSet<List<String>> 는 변환 불가능합니다. SortedSet 인스턴스의 변환은, null 이외의 comparator() 가 존재하면(자),IllegalArgumentException 를 throw 해 실패합니다.

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 에는,keyvalue 라는 이름의 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> 는 같은 방법으로 매핑 됩니다. 다만, 이것이 변환 가능한 것은,KComparable 를 구현하는 클래스 또는 인터페이스인 경우만입니다. 이 때문에,SortedMap<String, int[]> 는 변환 가능합니다만,SortedMap<int[], String> 는 변환 불가능합니다. SortedMap 인스턴스의 변환은, null 이외의 comparator() 가 존재하면(자),IllegalArgumentException 를 throw 해 실패합니다.

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 인터페이스 내부에서 참조되는 형태는, 다른 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 Server 의 MXBean 로서 등록할 필요가 있습니다.

ModuleMXBean.getProduct() 메소드는,Product 라는 이름의 속성을 정의합니다. 이 속성의 공개형은 SimpleType.OBJECTNAME 입니다. 대응하는 ObjectName 치는, 참조되는 ProductMXBean 가 MBean Server 내에서 등록되는 이름이 됩니다.

ModuleMXBean 용의 MXBean 프록시를 작성해, 그 getProduct() 메소드를 호출하는 경우, 다른 MXBean 프록시를 작성하는 것으로써, 프록시가 ObjectNameProductMXBean 에 재차 매핑 합니다. 즉,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 가 됩니다. 이 속성을 설정하는 경우는,ObjectNamesetProduct 메소드로 필요한 ProductMXBean 객체로 변환합니다. 이 객체는, 같은 MBean Server 내의 지정된 ObjectName 의 MXBean 프록시가 됩니다.

{ModuleMXBean 용의 MXBean 프록시를 작성해 그 setProduct 메소드를 호출하는 경우, 프록시는 그 ProductMXBean 인수를 ObjectName 에 재차 매핑 합니다. 이것이 기능하는 것은, 인수가 실제로, 같은 MBeanServerConnection 내의 ProductMXBean 에 대응하는 다른 프록시인 경우만입니다. 프록시는, 다른 프록시로부터 반환되는 일이 있습니다 (예를 들어,ModuleMXBean.getProduct()ProductMXBean 용의 프록시를 돌려준다). 또,JMX.newMXBeanProxy 에 의해 작성되는 일도,MBeanServerInvocationHandler 또는 서브 클래스인 호출 핸들러를 가지는 Proxy 를 사용해 작성되는 일도 있습니다.

2 개(살)이 다른 ObjectName 에 같은 MXBean 가 등록되어 있으면(자), 다른 MXBean 로부터 그 MXBean 에의 참조가 애매하게 됩니다. 이 때문에, MBean Server 에 등록을 마친 MXBean 객체를, 다른 이름으로 같은 MBean Server 에 등록하려고 하면(자),InstanceAlreadyExistsException 가 throw 됩니다. 일반적으로, 1 개의 MBean 객체를 복수의 이름으로 등록하는 것은 피해 주세요. 특히,NotificationBroadcaster 인 MBean 에서는, 올바르게 동작하지 않습니다.

그 외의 형태의 매핑

Java 클래스나 인터페이스 J 가 상기의 겉(표)에 나타낸 그 다른 룰에 들어맞지 않는 경우, 다음에 나타내도록(듯이), MXBean 시스템에 의해 CompositeType 에의 매핑이 시도됩니다. 이 CompositeType 의 형명은, 다음의형명 룰에 따라 결정됩니다.

취득 메소드의 클래스는,상기의 규칙을 사용해 검사됩니다(취득 메소드는 public 인스턴스 메소드가 아니면 안된다). 취득 메소드가 존재하지 않는지, 취득 메소드의 형태가 변환 불가능한 경우,J 는 변환 불가능합니다.

1 개(살) 이상의 취득 메소드가 존재해, 어느 취득 메소드에도 변환 가능한 형태가 존재하는 경우,opentype(J) 는 각 취득 메소드용의 항목을 1 개 보관 유지하는 CompositeType 입니다. 다음의 취득 메소드의 경우,

T getName()
CompositeType 내의 항목은 name 로 불려opentype(T) 형을 가집니다. 예를 들어, 다음의 항목의 경우,
String getOwner()
항목은 owner 로 불려 공개형 SimpleType.STRING 를 가집니다. 다음의 취득 메소드의 경우,
boolean isName()
CompositeType 내의 항목은 name 로 불려SimpleType.BOOLEAN 형을 가집니다.

최초의 문자 (코드 포인트)가, 소문자에 변환되는 것에 유의해 주세요. 이것은 Java Beans 의 규칙에 따르고 있습니다. 역사적인 이유로부터, 이것은 Standard MBean 의 규칙과는 다릅니다. Standard MBean 또는 MXBean 인터페이스에서는 getOwner 메소드는 Owner 라는 이름의 속성을 정의해, Java Bean 또는 맵 된 CompositeType 에서는 getOwner 메소드는 owner 라는 이름의 프로퍼티 또는 항목을 정의합니다.

2 개의 메소드가 같은 항목명을 생성하는 경우 (getOwnerisOwner,getOwnergetowner 등), 형태의 변환은 불가능합니다.

공개형이 CompositeType 의 경우, 대응하는 맵 된 Java 형 (opendata(J))는 CompositeData 가 됩니다. J 의 인스턴스로부터, 상기의 CompositeType 에 대응하는 CompositeData 에의 매핑은, 다음과 같이 실행됩니다. 최초로,JCompositeDataView 인터페이스를 구현하는 경우, 그 인터페이스의 toCompositeData 메소드가 불려 가, 변환이 실행됩니다. 그 이외의 경우는, 항목 마다 취득 메소드를 호출해 대응하는 공개 데이터형으로 변환하는 것으로,CompositeData 가 구축됩니다. 이것에 의해, 다음과 같은 취득 메소드가,

List<String> getNames()

이름 「names」 및 공개형 ArrayType(1, SimpleType.STRING) 의 항목에 매핑 됩니다. CompositeData 에의 변환에 의해 getNames() 가 불려 가 생성된 List<String> 가 항목 「names」의 String[] 에 변환됩니다.

CompositeData 는 인터페이스입니다. 형태를 공개 데이터로서 표현하는데 사용되는 구상 클래스는,CompositeDataSupport 또는 CompositeDataSupport 로서 직렬화하는 CompositeData 를 구현하는 다른 클래스입니다.

CompositeData 로부터 Java 형 J 의 인스턴스를 재구축 한다

opendata(J) 가 Java 형 JCompositeData 인 경우,J 의 인스턴스를 CompositeData 로부터 재구축 가능한가,J 는 재구축 불가능한가의 어딘가에 됩니다. CompositeData 내의 몇개의 항목이 재구축 불가능한 경우,J 도 재구축 불가능합니다.

지정한 임의의 J 에 관해서,CompositeData 로부터 J 의 인스턴스를 재구축 할 때, 다음의 룰이 적용됩니다. 리스트내에서 적용 가능한 최초의 룰이 사용됩니다.

  1. J
    public static J from(CompositeData cd) 메소드를 가지는 경우,
    그 메소드를 호출하는 것으로 J 의 인스턴스가 재구축 됩니다.

  2. 그 이외로,JConstructorProperties 주석을 포함한 1 개(살) 이상의 public 생성자 을 가지는 경우는, 이러한 생성자 의 1 개 (항상 같은 생성자 일 필요는 없다)를 호출해,J 의 인스턴스가 재구축 됩니다. 이러한 모든 주석은, 생성자 이 가지는 파라미터와 동일한 캐릭터 라인을 리스트에 포함할 필요가 있습니다. 각 캐릭터 라인은 J 의 취득 메소드에 대응하는 프로퍼티의 이름으로 합니다. 이 취득 메소드의 형태는, 대응하는 생성자 파라미터와 같게 할 필요가 있습니다. ConstructorProperties 주석에 기술되어 있지 않은 취득 메소드가 존재한다고 해도, 그것은 에러가 아닙니다. 이것들은, 객체의 재구축에는 불필요한 정보에 관련한 메소드일 가능성이 있습니다.

    J 의 인스턴스는,CompositeData 로부터 재구축 된 적절한 항목을 사용해 생성자 을 호출하는 것으로 재구축 됩니다. 이 CompositeData 는, 일부의 항목이 존재하고 있지 않았던 이전의 버젼의 J 에 유래하는 것일 가능성이 있습니다. 이 때문에, 불려 가는 생성자 은,CompositeData 내에 실재하는 항목에 근거해 실행시로 결정됩니다. 생성자 이 「적용 가능」이 되는 것은,ConstructorProperties 주석에 기재된 모든 프로퍼티이 CompositeData 내에 항목으로서 존재하는 경우입니다. 적용 가능한 생성자 이 존재하지 않는 경우는,J 를 재구축 하는 시도는 실패합니다.

    프로퍼티을 임의에 조합하는 경우는, 다음이 있지 않고 가가 들어맞읍니다. (a) 적용 가능한 생성자 이 존재하지 않는, (b) 적용 가능한 생성자 이 1 개만 존재하는, (c) 적용 가능한 생성자 의 1 개가, 다른 적용 가능한 각 생성자 이 지정한 프로퍼티의 적절한 슈퍼 세트를 지정한다. 즉, 선택하는 생성자 에 관해서 애매함은 존재하지 않게 됩니다. 이 조건이 true 가 아닌 경우,J 는 재구축 가능하지는 않습니다.

  3. 그 이외로,J 가 인수의 없는 public 생성자 을 가져, 형태가 T 로 이름이 NJ 내의 각 취득 메소드에 대해서 같은 이름과 형태의 대응하는 설정 메소드가 존재하는 경우는,J 의 인스턴스가 인수의 없는 생성자 을 사용해 구축되어 설정 메소드가 CompositeData 로부터 재구축 된 항목을 사용해 불려 가 값이 복원됩니다. 예를 들어,
    public List<String> getNames() 메소드가 존재하는 경우,
    이 룰이 적용된다
    public void setNames(List<String> names) 메소드도
    존재할 필요가 있습니다.

    CompositeDataJ 의 이전의 버젼에 근거하는 경우, 일부의 항목이 존재하지 않을 가능성이 있습니다. 이 경우, 대응하는 설정 메소드는 불려 가지 않습니다.

  4. 그 이외로,J 가 취득 메소드 이외의 메소드를 가지지 않는 인터페이스인 경우,J 의 인스턴스는,Proxy 를 사용해 구축됩니다. 그 때, 변환 대상의 CompositeData 를 이용하는 CompositeDataInvocationHandler 가 사용됩니다.

  5. 그 이외의 경우,J 는 재구축 불가능합니다.

이하의 예에서는,intString 로 구성되는 NamedNumber 형을 코딩 하는 몇개의 방법을 나타냅니다. 어느 경우에서도,CompositeType 는 다음과 같이 됩니다.

CompositeType (
    "NamedNumber",                      // typeName
    "NamedNumber",                      // description
    new String[] {"number", "name"},    // itemNames
    new String[] {"number", "name"},    // itemDescriptions
    new OpenType[] {SimpleType.INTEGER,
                    SimpleType.STRING}  // itemTypes
);
      
  1. static 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 생성자:
    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. 각 취득 메소드용의 설정 메소드:
    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. 취득 메소드만을 가지는 인터페이스:
    public interface NamedNumber {
        public int getNumber();
        public String getName();
    }
              

데이터의 컬렉션을 표현할 뿐(만큼)의 클래스는, 일반적으로, 「불변」으로 해 두는 것을 추천합니다. 불변 클래스의 인스턴스는, 구축 후로 변경할 수 없습니다. CompositeData 자체는 불변인 것에 유의해 주세요. 불변인 것에는 다수의 이점이 있습니다. 특히 thread의 안전성이나 시큐리티면에서 큰 메리트가 있습니다. 이 때문에, 설정 메소드의 사용은, 가능한 경우는 피하도록 해 주세요.

재귀형

재귀 (자기 참조) 형을 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 에 대응한 MBeanInfo 의 내용

MXBean 는, Open MBean 의 일종입니다. 다만, 호환성을 유지하기 위해(때문에),MBeanInfoOpenMBeanInfo 와 다르고 있습니다. 특히, 속성, 파라미터, 오퍼레이션의 반환값의 형태가 int 등의 원시형 또는 void (반환값의 형태)인 경우, 속성, 파라미터, 오퍼레이션은 각각 MBeanAttributeInfo ,MBeanParameterInfo ,MBeanOperationInfo 로 나타내집니다. 이러한 getType() 또는 getReturnType() 는 프리미티브(primitive)명 (int 등)을 돌려줍니다. 상기의 매핑 룰로,opendata 매핑이 랩 되는 형태 (Integer 등)와 지정되는 경우에서도, 이것은 들어맞읍니다.

MXBean 의 MBeanInfo.getConstructors() 가 돌려주는 public 생성자 의 배열 (MBean Server 에 직접 등록되기)에는, 그 MXBean 의 public 생성자 이 모두 포함됩니다. MXBean 의 클래스가 public 가 아닌 경우, 생성자 도 public 가 아니다고 보입니다. StandardMBean 클래스를 사용해 구축되는 MXBean 에 대해서 반환되는 리스트는, Standard MBean 와 같은 방법으로 취득됩니다. MXBean 의 구축 방법으로 관계없이, 생성자 파라미터는 MXBean 매핑 룰의 영향을 받지 않고, 대응하는 OpenType 를 가지지 않습니다.

MBean Server 내에 직접 등록되는 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 필드를 가집니다. 이 캐릭터 라인의 서식에 대해서는, 다음의「형명」을 참조해 주세요.

MBeanInfoDescriptor 는, 캐릭터 라인 「true」를 값으로 하는 mxbean 필드를 가집니다.

형명

MXBean 내의 메소드 파라미터나 반환값의 맵되어 있지 않은 형태 T 를 캐릭터 라인으로서 표현하는 것이 필요한 경우가 있습니다. T 가 총칭형이 아닌 경우, 이 캐릭터 라인은 Class.getName() 에 의해 반환되는 값이 됩니다. 그 이외의 경우, 이것은 genericstring(T) 의 값이 됩니다. 다음에 이 정의를 나타냅니다.

메소드가 int[] 를 돌려주는 경우는, 이것은,Class.getName() 에 의해 반환되는 캐릭터 라인 "[I" 로 나타내집니다. 다만, 메소드가 List<int[]> 를 돌려주는 경우, 이것은 캐릭터 라인 "java.util.List<int[]>" 로 나타내집니다.

예외

Java 형으로부터 공개형에의 매핑으로 문제가 발생하면(자),OpenDataException 에 의해 통지됩니다. 이것은, 취득 메소드를 가지지 않는 java.util.Random 등의 형태를 참조하는 경우 등, MXBean 인터페이스의 분석중에 발생하는 일이 있습니다. 또, 인스턴스의 변환중 (MXBean 내의 메소드로부터의 반환값 또는 MXBean 프록시내의 메소드에의 파라미터)에 발생하는 일도 있습니다. 예를 들어,SortedSet 가 null 이외의 Comparator 를 가지는 경우에,SortedSet<String> 로부터 String[] 로 변환할 때 발생합니다.

공개형으로부터 Java 형에의 매핑으로 문제가 발생하면(자),InvalidObjectException 에 의해 통지됩니다. 이것은, 재구축 가능한 형태가 필수의 문맥으로, 상기의 룰에 따르면(자) 「재구축 가능」이 아닌 형태를 참조하는 경우 등, MXBean 인터페이스의 분석중에 발생하는 일이 있습니다. 또, 해당하는 이름의 Enum 정수가 존재하지 않는 상황으로 String 로부터 Enum 에의 변환을 실시하는 경우와 같이, 인스턴스의 변환중 (MXBean 내의 메소드에의 파라미터 또는 MXBean 프록시내의 메소드로부터의 반환값)에 발생하는 일도 있습니다.

문맥에 응해,OpenDataException 또는 InvalidObjectException 를,RuntimeMBeanExceptionUndeclaredThrowableException 등의 다른 예외내에 랩 할 수 있습니다. throw 되는 예외 각각으로, 조건 C 가 true 가 됩니다. "eOpenDataExceptionInvalidObjectException 의 언젠가 적절한 (분)편입니다. 또,Ce. getCause() " 의 true 입니다.

도입된 버젼:
1.6

임의 요소의 개요
 boolean value
          주석 첨부 인터페이스가 MXBean 인터페이스인 경우, true 가 됩니다.
 

value

public abstract boolean value
주석 첨부 인터페이스가 MXBean 인터페이스인 경우, true 가 됩니다.

반환값:
주석 첨부 인터페이스가 MXBean 인터페이스인 경우는 true
디폴트:
true

JavaTM Platform
Standard Ed. 6

버그의 보고와 기능의 요청
한층 더 자세한 API 레퍼런스 및 개발자 문서에 대해서는,Java SE 개발자용 문서를 참조해 주세요. 개발자전용의 상세한 해설, 개념의 개요, 용어의 정의, 버그의 회피책, 및 코드 실례가 포함되어 있습니다.

Copyright 2006 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms . Documentation Redistribution Policy 도 참조해 주세요.