Re: [ccmtools-users] building ccmtools -- javax.jmi.reflect

[Egon T. <ego...@ut...>]

Hey Darrell!

Darrell Schiebel wrote:
> On Tuesday, November 9 2004 at 20:29+0100, Egon Teiniker wrote: 
> 	OK, with this fixed, I was able to generate and run the local
> 	component with no further problems... However, now I'm having
> 	trouble getting the remote component to work.
> 
> 	I'm still using "example1" from the tutorial. I created all of
> 	the pieces via:
> 
> 	ccmtools-generate c++local -a -o CarRental.remote *.idl
> 	ccmtools-generate idl2 -o CarRental.remote/CORBA_Stubs *.idl
> 	ccmtools-generate c++remote -o CarRental.remote *.idl
> 	ccmtools-generate c++remote-test -o CarRental.remote *.idl
> 	cp impl/CarRental_business_impl.cc impl/CarRental_impl.h \
> 	   impl/CarRental_maintenance_impl.cc CarRental.remote/impl
> 
> 	(the implementation files are the ones which came with example1
> 	in the ccmtools distribution). Next, I compile all of these
> 	things into these shared libraries:
> 
> 	       libCCM_Local_BigBusiness_CCM_Session_CarRental.dylib
> 	       libCCM_Remote_BigBusiness_CCM_Session_CarRental.dylib
> 	       libCORBA_Converter.dylib
> 	       libCORBA_Stubs.dylib
> 	       libCarRental_impl.dylib
> 
> 	All seems fine... next I copied the remote test program from
> 	example1/test, fixed it up, and then linked the test with:
> 
> 	c++ -DUSING_CONFIX -Wno-long-double -g -I/opt/local/include \
> 	    -I$destroot/include -o try \
> 	    _check_CCM_Remote_BigBusiness_CCM_Session_CarRental_remote.cc \
> 	    -L$destroot/lib -lCCM_Remote_BigBusiness_CCM_Session_CarRental \
> 	    -lCCM_Remote_CCM_Session_Container -lCORBA_Stubs \
> 	    -L/opt/local/lib -lWX_Utils_types -lWX_Utils_error \
> 	    -lWX_Utils_code -lmicocoss2.3.11 -lmico2.3.11
> 
> 	This links fine... but now how do I get micod (or whatever)
> 	to load the component when needed? What does it load? One
> 	of these shared libraries?

To run a remote component you can simple use the make check option of 
confix:

$ confix.py --bootstrap --configure --make --targets=check

If you look at your test directory, there is a _check*_remote*.cc file 
that activates the remote component and a collocated client.
To make the test run, make sure that a CORBA NameService is running. 
There are start scripts in cpp-environment/bin:

- runNameService: starts the Mico NameService
- runNSAdmin: starts Mico's NameService administrator tool

Also make sure that you have set the following environment variable

$ export CCM_NAME_SERVICE=corbaloc:iiop:1.2@localhost:5050/NameService

Currently, there is no support for loading components as shared 
libraries, thus, a CORBA server must be implemented manually.
This simple means that you must uncomment the // orb->run() line in the 
generated _check_*remote*.cc file and run the test again.

> 	A couple of other minor points... It would be nice if instead of
> 	using 'USING_CONFIX' to switch on/off what path should be used
> 	to include the header files, you used something like
> 	'USING_CONFIX_PATHS'. I find that I have to define 'USING_CONFIX'
> 	even though I'm not, and I worry that at some point 'USING_CONFIX'
> 	will imply more than just different header paths. BTW, what
> 	do you use when you're not USING_CONFIX... just makefiles created
> 	by hand?

Oh yes, this is a bad hack that will be removed soon. We have used 
ccmtools in context of another build tool and needed a way to switch 
between confix and the other tool.

> 	Also, I had to make some changes to the Cpp templates to get the
> 	generated code to compile (I think it's just an oversight), and
> 	I've included that patch file below.

Thanks for your investigation!
As you can see, the remote generator is not finished at all but its on 
the way...

:-) Egon