Options of the mogen compiler enable you to modify the characteristics of the stubs you generate from an m-bean. For example, options are available that enable you to generate read-only or read-write stubs. By generating from the same m-bean a set of stubs with different characteristics, you can develop a Java manager the behavior of which is modified at runtime, depending on which stubs are loaded. For example, when the read-only stubs are loaded, the Java manager will not be able to modify properties in the m-bean.
Command for Starting mogen
To start mogen, type the command for your operating environment:
|
prompt% /opt/SUNWconn/bin/mogen [options] class1...classN
|
|
C:\>"C:\Program Files\SUNWconn\jaw\bin\mogen" [options] class1...classN
|
|
mogen [-d dir] [-ro] [-f] [-l className] [-li className] [-nl] [-nlmo] [-nlas][-tp pkgName][-np] [-ne] [-nc] [-classpath path] [-help] class1...classN |
-d dir
-ro
-f
-l className
-li className
-nl
-nlmo
-nlas
-tp pkgName
-np
-ne
-nc
-classpath path
-help
| CODE EXAMPLE 6-1 Starting mogen |
Output of the mogen Compiler
For an m-bean defined in the Java class MyBean, the mogen compiler generates:
FIGURE 6-1 Output of the mogen Compiler for a Simple M-Bean
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" on page 188.
Mapping Rules
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.
Inheritance
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-2.
Note - When you compile an m-bean, no c-beans are generated for its superclasses. You have to compile these superclasses explicitly.
FIGURE 6-2 Default Translation of Inheritance in M-Beans
Generating a Flattened C-Bean
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-3.
FIGURE 6-3 Flattened C-Bean
Limiting the Flattening of a C-Bean
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
-l className option, there is no inheritance in the c-bean. This is illustrated in FIGURE 6-4. If you specify the -li className option, inheritance is preserved in the c-bean. This is illustrated in FIGURE 6-5.
FIGURE 6-4 Limiting the Flattening of a C-Bean - no Inheritance
FIGURE 6-5 Limiting the Flattening of a C-Bean - Inheritance preserved
prompt % mogen -f C
|
prompt % mogen -li A C
|
Properties
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. Methods
In addition to the property accessors, mogen generates code only for public methods complying with the action design pattern defined in "Actions" on page 39. 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 CODE EXAMPLE 6-2.
The code generated in the MO interface from this definition is shown in CODE EXAMPLE 6-3. The code shown in CODE EXAMPLE 6-3 is a subset of the code mogen generates in the MO interface when compiling the m-bean.
| CODE EXAMPLE 6-3 Action Method in a C-Bean |
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. Methods Present Only in C-Beans
The c-beans that mogen generates also contain methods that are not present in the m-bean. They implement the methods defined in the Java interface com.sun.jaw.reference.client.mo.ManagedObject. These methods are public methods that do not follow the design patterns defined by the JavaBeans component model. Their purpose is to improve the performance of applications by:
The mogen compiler generates Java source code, not compiled Java classes. For your c-beans to be accessible to a Java manager, you have to compile the files that mogen generates, and make sure that the compiled Java classes are stored at a location specified in the
CLASSPATH environment variable of the manager. Developing Applications With Code From mogen
The applications you develop with the generated code are based on the Java interface that mogen generates. The stubs that mogen generates implement the methods defined in this interface. Options of the mogen compiler enable you to modify the characteristics of the stubs you generate from an m-bean for the same interface. For example, options are available that enable you to generate read-only or read-write stubs. Modifying the Code Generated by mogen
If you want to define a specific view of an m-bean, you can modify the generated code. To ensure that the modified code remains consistent with the m-bean it represents, do not modify the interface; modify only the stub.