Notes regarding Java examples in omniORB2.
==========================================

Compiling
---------

omniORB2 comes with various examples of Java code to interact with it
in the src/java directory.  The build mechanism for these is a tad
clunky, and will probably need some customisation for your local
environment.

To tell the system where your Java implementation is, you need to set
a variable in your platform .mk file or config.mk:

$(JAVA_ROOT)	-- The root of your JDK installation.
$(JAVAIDL_ROOT)	-- The root of your Java IDL installation. (optional)
$(VBJ_ROOT)	-- The root of your VisiBroker for Java installation.
								(optional)

I'm not quite sure how this'll behave with JDK 1.2, which has Java IDL
built-in.  You'll need to get idl2java separately anyway.

The choice of which Java ORB to use for a particular package is made
in the dir.mk file, since in our local environment, config.mk is
automatically generated.  You need one of:

JavaORB = JAVAIDL
or
JavaORB = VBJ
.

I've left it saying "JAVAIDL" since that's all I've tested it with.

Doing a 'gnumake export' will create 'classes' and 'javaidl_stubs'
and/or 'vbj_stubs' directories at the top of the tree.  'classes' and
one of the stub directories should be in your CLASSPATH before trying
to run any of the examples.

If you use another Java ORB, or can't get the magic Makefiles to work
(I'm not surprised), you should be able to compile idl/echo.idl with
your IDL compiler (put the results in the UK.co.orl.omniorb package)
and compile the classes by hand using javac.


What there is
-------------

The directory structure under src/java mirrors the Java package
structure, for reasons related to the development environment we use.

The examples in the UK.co.orl.omniorb package are roughly Java
equivalents of the examples in src/examples/echo.  There's no
equivalent of eg1, since this wouldn't be interesting (we're
demonstrating omniORB, not your favourite Java ORB).

Anyway, the examples you get are:

UK.co.orl.omniorb.eg2_impl	-- Echo server which puts a
				stringified IOR on stderr.
UK.co.orl.omniorb.eg2_clt	-- Echo client which reads a
				stringified IOR from the
				command-line. 
UK.co.orl.omniorb.eg3_impl	-- Echo server which registers
				itself with a name server.
UK.co.orl.omniorb.eg3_clt	-- Echo client which uses a name
				server to find a server.

Note that the versions which use a naming service make two attepmts at
contatcting the service.  First, using resolve_initial_references on
the ORB object, and if that fails, by pretending to be omniORB, and
digging out omniORB's configuration file.  This is tricky with JDK
1.1, since Sun have stopped us using System.getenv.  Instead, the
location of the omniORB config file is looked for in the system
property "UK.co.orl.omniorb.configFile", so you should invoke Java as
(eg): 

java -DUK.co.orl.omniorb.configFile=$OMNIORB_CONFIG UK.co.orl.omniorb.eg3_clt

If you're using Java IDL, resolve_initial_references can be made to
work with the aid of com.sun.CosNaming.BootstrapServer.  See
<URL:http://www.orl.co.uk/~bjh/omniORB-JavaIDL-HOWTO.html> for
details.

As I remember, VBJ is incapable of handling a
resolve_initial_references request for naming service, so VBJ users
will have to rely on UK.co.orl.omniorb.OmniOrbConfig (the class that
handles finding and reading omniORB's configuration file).

UK.co.orl.weather.Weatherman	-- Client for our local weather
				server.

Weatherman expects the IOR of the weather server on the command line.
There's a skeleton shell script in bin/scripts/java_weatherman which
needs a suitable IOR putting in it.  We'll publish an IOR once we've
got a weather server in a state to let external clients play with it.
