EAServer Manager displays IDL modules as folders beneath the top-level IDL folder. Modules can be nested, that is, a module may be defined within another module.
Follow this procedure to view the IDL entities defined within a module.
Expand the top-level IDL folder.
Each icon in the IDL folder represents a top-level IDL module. To navigate to a nested module, click the + sign next to the parent module’s icon, or double-click the parent module’s icon.
In the left pane, highlight the module of interest. EAServer Manager display the types and modules defined within the highlighted module in the right pane.
If defining a new top-level module, highlight the IDL folder.
If defining a nested module, follow the steps in “Navigating nested IDL modules” to highlight the parent module.
Choose File | New IDL Module. Enter the module name and click Create New Nested Module IDL. Module names must begin with a letter.
EAServer Manager displays the empty module definition in the IDL Editor window. Optionally make the following changes:
Edit the HTML documentation comment and add a description of the module.
If the module will contain datatypes and interfaces (and not just nested modules), optionally specify the Java package for stubs as described by “Specifying Java package mappings for IDL modules”.
When done, choose File | Save, then File | Exit to close the IDL Editor window.
Specifying Java package mappings for IDL modules
If an IDL module contains datatypes and interfaces (and not just nested modules), you can specify the Java package to be used for generated Java stubs. Stubs for each type of Java client must be in different packages, or deployed under different code bases.
If you do not specify a Java package mapping, stubs are generated to a package that matches the IDL module name. For example, stubs for module foo::bar are generated in Java package foo.bar.
Change the Java package mapping for a module by editing one of the following files:
Repository/IDL/ejb.props specifies the Java packages for EJB stubs.
Repository/IDL/java.props specifies the Java packages for Java/CORBA stubs.
Repository/IDL/jdbc.props specifies the Java packages for EAServer 1.1 stubs.
To change the default Java package, create or edit an entry in the appropriate file with this format:
idl-module=dotty-package
Where:
idl-module is the IDL module name, for example, com::sybase::test::MyModule
dotty-package is the dot-format Java package name, for example, com.sybase.test.corba.
For compatibility with IDL created in previous releases, EAServer also allows you to specify the Java package in a doc comment directives above the module declaration. These directives are translated to entries in the java.props, ejb.props, or jdbc.props files. You can enter multiple directives to specify packages for stubs of different types. Each package directive has the form:
/* ** <!-- typePackage: dotty-package --> */
Where dotty-package is the dot-format Java package name and type is one of:
java, if specifying
the package for CORBA stubs.
ejb, if specifying
the package for EJB stubs.
jdbc, if specifying
the package for Jaguar 1.1 client stubs.
You can also create or change Java package mappings when generating stubs for the IDL module in EAServer Manager. Highlight the IDL module and choose File | Generate Stubs. Choose the stub type and enter a different Java package name in the Java Package field.
Creating IDL types, exceptions,
and interfaces
Follow this procedure to define new datatypes and exceptions in a module. You can also define new component interfaces with this procedure, but it is easier to define interfaces using the component’s Interfaces folder (see “Defining interfaces graphically”).
Navigate to and highlight the module where the entity is being created, as described in “Navigating nested IDL modules”.
Choose File | New IDL Entity.
In the New IDL Entity dialog box, enter a name for the type or interface, then choose the type of entity being created. Click Create New IDL Entity.
EAServer Manager displays a template for the new IDL definition in the IDL Editor window.
Finish the definition, then choose File | Save and File | Exit to close the IDL Editor window.
EAServer allows forward IDL references
You can create new IDL types that refer to other IDL types
that do not yet exist; among other benefits, this feature allows
you to create mutually recursive interface definitions. However,
you must be sure that all references are resolved before you can
generate stubs and skeletons. When generating stubs and skeletons,
EAServer Manager will report errors for any unresolved type references.
Editing IDL types, exceptions,
and interfaces
To edit or delete a type, exception, or interface:
Navigate to and highlight the module where the entity is being created, as described in “Navigating nested IDL modules”.
The module’s types, exceptions, and interfaces display in the right pane of the EAServer Manager window.
To edit an item, highlight it and choose File | Edit Entity IDL. Make your changes in the IDL editor window, save them, and close the window.
To delete an item, highlight its icon and choose File | Delete.
Unreferenced IDL definitions
The interfaces, types and exceptions associated with a component
are not deleted when you delete the component from EAServer Manager unless
you delete the package or application where it is installed and
specify full deletion. Unused definitions cause no harm. When generating
Java stubs, stub classes are generated for all types in a module,
regardless of whether the component references them. You can delete
unreferenced IDL types to prevent the generation of unnecessary
Java stub classes. Verify that no other component references an
IDL definition before deleting it.
When deleting packages, you can delete everything associated with the package, including IDL definitions, by choosing full deletion as described in “Modifying packages”.
