Java Dynamic Management Kit 3.2 Programming Guide | ||||
---|---|---|---|---|
![]() | ![]() | Chapter 6. C-Beans | ![]() | ![]() |
For an m-bean defined in the Java class BeanName, the mogen compiler generates:
A Java interface (BeanNameMO), which defines the methods of the m-bean that are accessible to a Java manager
A Java stub (BeanNameMOStub), which implements the methods defined in the Java interface BeanNameMO
For example, when an m-bean representing a Java class named Simple is compiled, mogen generates the source code of:
A Java interface named SimpleMO
A Java class named SimpleMOStub, which implements the SimpleMO interface
This is illustrated in Figure 6-2.
An example showing a simple m-bean and the Java interface that mogen generates when compiling this simple m-bean is given in Chapter 2.
Note - For an m-bean that uses listeners, mogen generates additional files, as described in Output From mogen for an M-Bean With Listeners and Events in Chapter 15.
The mogen compiler uses the Java Reflection API for analyzing an m-bean and generating its associated c-bean. It parses an m-bean using the design patterns defined in Chapter 3. The mapping rules that mogen uses for generating the c-bean are described in the following subsections.
By default, the mogen compiler translates inheritance expressed in m-beans into inheritance from c-beans. When you compile an m-bean that inherits methods and attributes from another m-bean, the inheritance of methods and attributes in the m-bean is duplicated in the c-bean generated. For example if m-bean B inherits from m-bean A, compiling B generates B', which corresponds to m-bean B and inherits from c-bean A'. Similarly, if m-bean C inherits from m-bean B, compiling C generates C', which corresponds to m-bean C and inherits from c-bean B'. This is illustrated in Figure 6-3.
Note - When you compile an m-bean, no c-beans are generated for its superclasses. You have to compile these superclasses explicitly.
Options of the mogen compiler enable you to generate flattened c-beans and to limit the scope of inheritance in c-beans.
To generate a flattened c-bean, specify the -f option in the command to start mogen. In a flattened c-bean, all methods and attributes that the m-bean inherits are included in the generated c-bean. This is illustrated in Figure 6-4.
To limit the flattening of a c-bean, specify one of these options in the command to start mogen:
-l className - no inheritance in the c-bean
-li className - inheritance preserved in the c-bean
In the flattened c-bean, the methods and attributes inherited by className are not included. If you specify the -l className option, there is no inheritance in the c-bean. This is illustrated in Figure 6-5. If you specify the -li className option, inheritance is preserved in the c-bean. This is illustrated in Figure 6-6.
Notice that these two commands produce the same output:
prompt% mogen -f C |
prompt% mogen -li A C |
Each property of the m-bean is present in the c-bean with the same accessor methods. Therefore, if a property is read-only in the m-bean, the property is read-only in the generated c-bean.
In addition to the property accessors, mogen generates code only for public methods complying with the action design pattern defined in Actions in Chapter 3. Other public methods do not appear in the c-bean generated by mogen.
An example of the definition of an action method in an m-bean is shown in Example 6-1.
Example 6-1. Action Method in an M-Bean
public class simpleMBean implements java.io.Serializable { ... public void performReverse() { StringBuffer buf = new StringBuffer(name); name = buf.reverse().toString(); } public Boolean performReverse(Integer nFirst) { StringBuffer buf = new StringBuffer(); int n = nFirst.intValue(); if (name.length() < n + 1) { return (new Boolean(false)); } buf.append(name.substring(0, n)); name = new String(buf.reverse().toString() + name.substring(n)); return (new Boolean(true)); } ... } |
The code generated in the MO interface from this definition is shown in Example 6-2. The code shown in Example 6-2 is a subset of the code mogen generates in the MO interface when compiling the m-bean.
Example 6-2. Action Method in a C-Bean
public interface simpleMBeanMO extends ManagedObject { ... public Boolean performReverse(Integer p0) throws InstanceNotFoundException, CommunicationException, IllegalAccessException, ServiceNotFoundException, NoSuchMethodException; public void performReverse() throws InstanceNotFoundException, CommunicationException, IllegalAccessException, ServiceNotFoundException, NoSuchMethodException; ... } |
Options of the mogen compiler enable you to generate a c-bean without any code for actions. This is useful if you want to reduce the size of a c-bean, or if you want to prevent a user of the Java manager from performing actions on the m-bean. To generate a c-bean without any code for actions, specify the -np option in the command to start mogen.
The mogen compiler enables you to generate c-beans from m-beans that implement interfaces. When the m-bean is compiled, mogen generates an interface and a stub that implements the interface. In order to preserve the relationship between the original m-bean and the interfaces that it implements, mogen must be used twice. The first compilation is performed on the interfaces that the m-bean implements, IMO and IMOStub are generated. The second compilation is performed on the m-bean itself, CMO and CMOStub are generated.
To generate c-beans from m-beans that implement interfaces, specify one of these options in the command to start mogen.
-i - the CMO interface generated extends the IMO interfaces that mogen generates, in the first compilation, from the interfaces implemented by the m-bean.
-iall - the c-bean generated extends the interfaces that mogen generates, in the first compilation, from the interfaces implemented by the m-bean and the interfaces implemented by the inherited classes up to the level specified by the -f, -l, or -li option.
The options -i and -iall are mutually exclusive. The -iall must be associated with -f, -l or -li to supply the ClassName parameter.
This procedure assumes that you have an m-bean called Bean, that implements the interface BeanInterface.
prompt% mogen BeanInterface |
This generates an interface BeanInterfaceMO and a c-bean which implements it calledBeanInterfaceMOStub. The c-bean BeanInterfaceMOStub is not required and can be deleted.
prompt% mogen -i Bean |
This generates an interface BeanMO and a c-bean which implements it called BeanMOStub. The interface BeanMO extends the interface BeanInterfaceMO generated in the previous step.
The c-beans that mogen generates also contain methods that are not present in the m-bean. Rather, they are defined in the Java interface com.sun.jaw.reference.client.mo.ManagedObject. The c-bean's interface extends this interface, and code generated in the stub implements its methods. These methods are public methods that do not follow the design patterns defined by the JavaBeans component model.
These methods provide additional functionality for c-beans and the management applications which instantiate them. Their purpose is to improve the performance of applications by:
Limiting the network traffic between an m-bean and a c-bean. For example, methods are defined which, when invoked on a c-bean, perform operations on several properties of its corresponding m-bean.
Freeing resources when they are no longer required. For example, a method is defined for deleting a c-bean automatically when its corresponding m-bean is deleted.
Making sure that the information provided by c-beans is up to date. For example, methods are defined for connecting and disconnecting a c-bean from an adaptor client.
![]() | ![]() | ![]() |
Command for Starting mogen | ![]() | Using the Generated Code |