This is a feature of JBuilder Enterprise.
To open the VisiBroker IDL Properties dialog, right-click on an IDL file in the project pane, and select Properties. In order for this dialog to display, VisiBroker must be selected as the IDL Compiler from the Project|Project Properties Build page. The other IDL Compiler option is OrbixWeb.
The VisiBroker IDL Properties dialog enables you to specify options for compiling remote interfaces defined in the Interface Definition Language (IDL). When an IDL file is compiled, it generates Java interface definitions and Java client stubs and server skeletons. This allows a Java client to transparently invoke an IDL object that resides on a remote server or allows a Java server to define objects that can be transparently invoked from IDL clients.
When the IDL compiler, idl2java, a Java-based preprocessor, is invoked by right-clicking on an IDL file and selecting Make, the IDL source file is compiled, and a directory structure containing the Java mappings for the IDL declarations is created. Typically, one IDL file will be mapped to many Java files that marshall/unmarshall Java data types to CORBA types and provide IIOP messaging. IDL file names must end with the .idl extension. More information about this compiler is available in the VisiBroker for Java Reference Manual.
/opt/inprise/vbroker/examples/
directory.
VisiBroker for Java conforms with the OMG IDL/Java Language Mapping Specification.
When the Process This IDL File option is checked, selecting OK sets the options to be used by the VisiBroker tool idl2java
, a Java-based preprocessor, when the IDL file is compiled. Set the correct options so that when compiled, Java interface definitions and Java client and server stubs and skeletons are generated.
When the Process This IDL File option is not checked, selecting OK saves the selected options, but does not call the idl2java
compiler when the IDL file is compiled. This means that the client stubs and server skeletons are not generated when the IDL file is compiled.
The first step to creating an application of this type to specify all of your objects and their interfaces using the OMG's Interface Definition Language (IDL). The IDL can be mapped to a variety of programming languages. The IDL mapping for the Java language is summarized in the chapter titled "The IDL to Java Mapping" in the VisiBroker for Java Reference Manual.
The interface specification you created is used to generate stub routines for the client program and skeleton code for the object implementation. The stub routines are used by the client program for the method invocations. You use the skeleton code, along with code you write, to create the server that implements the object. The code for the client and object, once completed, is used as input to your Java compiler to produce a Java applet or application and an object server.
The options are discussed in more detail in the chapter titled "Programmer Tools" in the VisiBroker for Java Reference Manual.
If unselected, the portable stubs will not be generated. VisiBroker-specific extensions and optimizations will be present in the code that is generated. Generated stubs will specifically be for use in VisiBroker ORB environments.
When this flag is on, the compiler generates skeleton code using the Dynamic Skeleton Interface (DSI). To understand how to do any type of DSI, create an IDL file, select this option, compile, and look at the skeleton code.
For more information on this option, see the chapter titled "The Dynamic Skeleton Interface" in the VisiBroker Programmer's Guide.
The tie mechanism offers an alternative when it is not convenient or possible to have your implementation class inherit from the VisiBroker skeleton class. Object implementation classes must inherit from the VisiBroker skeleton class. Java does not allow multiple class inheritance and you may want your implementation class to inherit from a different class.
Inheritance is easier to use than the tie mechanism because implementation objects look and behave just like object references. If an implementation object happens to be in the same process as a client using it, operation invocations involve less overhead because no transport, indirection, or delegation of any kind is required.
The tie mechanism provides a delegator implementation class that inherits from org.omg.CORBA.Object. The delegator implementation class does not provide any semantics of its own. It simply delegates every call to the real implementation class, which can be implemented separately and can inherit from whichever class it wishes.
The Operations class defines all of the methods that must be implemented by the object implementation. This class acts as the delegate object for the associated _tie class when the tie mechanism is used.
For more information on this option, see the chapter titled "The Tie Mechanism" in the VisiBroker Programmer's Guide.
-idl2package idl pkg
.
Puts definitions in scope of idl into the specified Java package, for example:
-idl2package ::CORBA org.omg.CORBA
What this means is that if any part of the IDL file is in the scope ::CORBA, then the java code
generated for it is placed in the java package org.omg.CORBA.
In this example, the IDL has a module name of CORBA
. When the Java code is generated, these CORBA
classes should have the org.omg.CORBA
name space. To do this, set the idl2package option of ::CORBA
to org.omg.CORBA
.
When this option is not set, the idl2java compiler generates code using the CORBA package resolution rules.
#define name def
.
idl2java
, a Java-based preprocessor, when the IDL file is compiled. Set the correct options so that when compiled, Java interface definitions and Java client and server stubs and skeletons are generated in a subdirectory of the project with the same name as the project.
When the Process This IDL File option is not checked, selecting OK saves the selected options, but does not call the idl2java
compiler when the IDL file is compiled. This means that the client stubs and server skeletons are not generated when the IDL file is compiled.