In this chapter, we will briefly explain the executables that come with JacORB. These include the IDL-compiler and stub generator, the JacORB name server and the server for the interface repository. For users without C-Shells installed, the commandline for starting the utilities directly by starting the Java interpreter will be given.
The IDL compiler parses IDL specifications and maps these to a set of Java classes. IDL interfaces are translated into Java interfaces, and typedefs, structs, const declarations etc. are mapped onto "equivalent" Java classes. For a description of the Java language mapping please see [1] Using the idl utility, stubs and skeletons for all interface types in the IDL specification will automatically be generated.
If want only IDL mapping without stubs generation, use the idl2j utility instead. The syntax is the same for both commands.
idl [-syntax] [-p package_prefix ][-d <Output Directory>] file.idl
or
idl.bat [-syntax] [-p package_prefix ][-d <Output Directory>] file.idl
Invoking idl with the -syntax option allows you to check your IDL specification for syntactic errors without producing code. Without -syntax, the compiler creates directories according to the Java package structure.
Compiling a file with a module ModuleX and an interface InterfaceY in it will result in a subdirectory ModuleX with InterfaceY.java in it (and possibly more .java-files). By default, the root directory for all of the files created during the process is the current directory. You can, however, provide a different directory in which these files are to be placed by using the -d option. Using the -d option when you are only checking the syntax of an IDL file has no effect.
With the -p option it is also possible to specify a package prefix for the generated Java classes. E.g., if the IDL file contains a module Bank which defines an interface Account, you can direct the IDL compiler to generate Java classes example.Bank.Account by compiling with the package prefix set to example, i.e. by compiling with
idl -p example bank.idl
The IDL compiler will create the appropriate directories if necessary.
If you used idl2j, you will have to generate stubs and skeletons for selected interfaces in a separate step using jgen
(The IDL parser was generated with Scott Hudson's CUP parser generator. The LALR grammar for the CORBA IDL is in the file jacorb/Idl/parser.cup.)
The generator takes a .class-file (which can be compiled from a regular Java class or interface) and automatically constructs Java source code for a client and a server stub class from it.
It can also be used to derive a class's interface from its implementation or produce informative interface output about the class on stdout. It does more than the javap disassembler in that it traverses the whole inheritance graph of a class in order to list every method of your class -- the inherited ones as well as the ones defined in the class itself. There is one exception to this: methods inherited from class Object are not listed.
jgen [ options ] <file.class>
or
jgen.bat [ options ] <file.class>
or
java jacorb.generator.Main [ options ] <file.class>
The JacORB generator, when used without command line options, produces two files containing the Java source code for a client stub and a server skeleton.
$ jgen Game.class
generates GameStub.java and GameSkeleton.java which you can then compile and use.
Example:
$ jgen -i Game.class
generates a file GameInterface.java. You can check that it is ok by adding implements GameInterface to your class definition Game in Game.java and recompile.
In the produced interface file, every inherited method has a comment to it which indicates where it was inherited from, e.g.:
public void repaint(int, int, int, int);
// from java.awt.Component
Any method which is not accessible to the class the interface is derived from is commented out, so that the interface will compile correctly.
Example:
$ jgen -f jacorb/demo/cardgame/PlayerApp.class
(The -f means "flatten the inheritance structure").
JacORB provides a service for mapping names to network references. The name server itself is written in Java like the rest of the package and is a straightforward implementation of the CORBA "Naming Service" from Common Object Services Spec., Vol.1 [3]. The IDL interfaces are mapped to Java according to our Java mapping.
ns <filename>
or
ns.bat <filename>
or
java jacorb.Naming.NameServer <filename>
ns ~/public_html/NS_Ref
The name server does not use a well known port for its service and there is no way to direct it to a specific port. Since clients cannot (and need not) know in advance where the name service will be provided, we use a bootstrap file in which the name server records an opaque object reference to itself (its Interoperable Object Reference or IOR). The name of this bootstrap file has to be given as an argument to the ns command. This bootstrap file has to be available to clients networkwide, so we demand that it be reachable via a URL -- that is, there must be an appropriately configured HTTP server in your network domain which allows read access to the bootstrap file over a HTTP connection. (This implies that the file must have its read permissions set appropriately. If the binding to the name service fails, please check that this is the case.) After locating the name service through this mechanism, clients will connect to the name server directly, so the only HTTP overhead is in the first lookup of the server.
The name bindings in the server's database are mirrored in the bootstrap file, so you have a network wide readable log of which names are already in use.
This utility lists the contents of the default naming context. Only currently active servers that have registered are listed. The -r option recursively lists the contents of naming contexts contained in the root context.
lsns [ -r ] or
lsns.bat [ -r ]
or
java jacorb.Naming.lsns [ -r ]
$ lsns
/grid.service
when the server for the grid example is running.
In order to use the JacORB Interface Repository, a separate server process needs to be started "somewhere" in your network domain. Similar to the name server, the IR server takes a file name argument that will be used to store its IOR and make it accessible via a URL (as configured in Config.java) to the ORB so that it can find the IR server.
The second argument, the classpath, determines the contents of the Repository. The JacORB Interface Repository contains nothing but Java class files, and it will know only about the files in the particular class path given to the IR server at startup time.
ir <filename> [<classpath>]
or
ir.bat <filename> [<classpath>]
or
java jacorb.Orb.IR.Repository <filename> [<classpath>]
ir ~/public_html/IR_location ~/classes
This utility queries the IR for a particular repository identifier and prints the respective IDL definition to the screen.
qir <repository ID> or
qir.bat <repository ID>
or
java jacorb.Orb.IR.QueryIR <repository ID>
$ qir "IDL:omg.org/GIOP/LocateStatusType:1.0"
enum LocateStatusType UNKNOWN_OBJECT,OBJECT_HERE,OBJECT_FORWARD;
JacORB comes with a simple utility to decode an interaoperable object reference (IOR) in string form in to a more readable representation. In the following example we use it to print out the contents of the IOR that the JacORB name server writes to the client bootstrap file:
dior <IOR-string>
or
dior <IOR-string>
or
java jacorb.Orb.util.PrintIOR <IOR-string>
dior IOR:000000000000002849444c3a6f6d672e6f72672f436f7 34e616d696e672f4e616d696e67436f6e746578743a312e300000000001000000 000000002c000100000000000e3136302e34352e3131302e36370094590000001 0eee51bdce9d8222eded628696cf002c3 ------IOR components----- TypeId : IDL:omg.org/CosNaming/NamingContext:1.0 Profile Id : TAG_INTERNET_IOP IIOP Version : 1.0 Host : 160.45.110.67 Port : 37977 Object key : ����".��(il��