[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference pamsrc::objectbroker_development

Title:ObjectBroker Development - BEA Systems' CORBA
Notice:See note 2 for kit locations; note 4 for training
Moderator:RECV::GUMBELd
Created:Thu Dec 27 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2482
Total number of notes:13057

2468.0. "Client/server colocation?" by NNTPD::"[email protected]" (Paul Doyle) Tue Apr 15 1997 16:06

It should be possible to have a process acting as both 
server and client:

  interface I {
    void f(in I a, in string s);
    void g(in string s);
    };

  void 
  I_i::IImpl_f (I_ptr a, const char * s, CORBA::Environment &ev) 
  {
    cerr << s << " (called from f)" << endl;
    IImpl_g("fizzle", ev);
    a->g(CORBA::string_dup(s), ev);
  }

  void 
  I_i::IImpl_g (const char * s, CORBA::Environment &ev) 
  {
    cerr << s << " (called from g)" << endl;
  }

so a client with two I_ptr values can pass the second as 
an argument to a method call on the first; the first then 
invokes a method on the second.

There is no issue with this under Orbix.

Using ObjectBroker 2.7 on Digital Unix 3.2, C++ binding, 
I generate an external typcode file (using obbgen -x -T etc) 
but I can't see a way to tell IDispatch.cxx to use this - 
instead, obbgen duplicates (almost) the typecode definitions
in the Dispatch file.  Needless to say, I get nasty errors
when I try to link the server...

How is this done?

Thanks,

Paul

[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name		DateLines
2468.1Did you use -x option when generating client stubs & dispatcher?VAXCPU::michaudJeff Michaud - ObjectBrokerTue Apr 15 1997 21:4633
> Using ObjectBroker 2.7 on Digital Unix 3.2, C++ binding, 
> I generate an external typcode file (using obbgen -x -T etc) 
> but I can't see a way to tell IDispatch.cxx to use this - 
> instead, obbgen duplicates (almost) the typecode definitions
> in the Dispatch file.  Needless to say, I get nasty errors
> when I try to link the server...

	You didn't specify the options you used to generate the dispatch
	file, but my guess is you didn't specify the -x option when
	you generated it?

	The same goes when generating the client stubs.

	Ie.

	obbgen -x -T ....  - to generate the typecode file
	obbgen -x -c ....  - to generate the client stubs w/out typecode stuff
	obbgen -x -d ....  - to generate the dispatcher w/out typecode stuff

	Do note that I discovered one bug w/trying to use an external typecode
	file (ie. the -x option).  This was back in early '96 so it may be
	fixed in V2.7 (or possibly even V2.6), but I'm not sure.  Here's a
	quick summary:

For full details see QAR 2410.  The quick summary is that
when generating external typecodes [source] file(s) (vs.
duplicate code in both the generated stubs (client side) and
dispatch (server side), the _narrow function is still generated
in the stubs, not in the external typecode file, but the real
problem is when using external typecodes, _narrow is no longer
generated in the dispatch file.  Hence, you can compile both
client and server, but the server won't link due to _narrow
being unresolved.
2468.2obbgen -xNNTPD::&quot;[email protected]&quot;Paul DoyleWed Apr 16 1997 09:3344
Jeff,
       your reply was absolutely correct and I was able to get 
my simple example - and the real life code on which my example 
was based - working smoothly.  Thanks for your help.

So what was I doing wrong?  Well, it turns out the documentation 
is wrong on this.  The obbgen man page and the printed 
documentation (v2.6, distributed with 2.7) say the following:

" -T typecode-file    
(... stuff deleted ... )
If you specify the -x option, you must specify the -T option."

I can see now that that should read:
"If you specify the -T option, you must specify the -x option."
but believe me, it isn't an obvious error.

Much more significantly, under the "-x" option:

"You cannot specify the -x option by itself.  You must
 specify it with one of the following options:

 The -c option causes the typecode data and the functions to be 
 written to the client stubs module. (etc)"

Emmm - shouldn't the word "not" appear before "to be" in that 
sentence?  In other words, doesn't this say the exact opposite 
of what actually happens - typecode data and functions being 
written to a separate file?  

The same goes for the -d option, where I was tripping up.

The obbgen command format summary compounds this confusion.  
The "-x" option is not listed under the server application 
syntax.  The client application syntax shows the "-x -T" option 
only in conjunction with "-c", not on its own.  In fact, there is
no indication in the syntax summary that external typecode files 
can be generated independently of the generation of stub files.

Once again, thanks for the assistance.

Paul

[Posted by WWW Notes gateway]
2468.3WLDBIL::KILGOREBEAmer BillWed Apr 16 1997 09:573
    
    .2 entered as PTR 16-5-50
2468.4PTR 16-5-50NNTPD::&quot;[email protected]&quot;Paul DoyleWed Apr 16 1997 10:497
>    .2 entered as PTR 16-5-50
 
How do I monitor this PTR?

Paul
  
[Posted by WWW Notes gateway]
2468.5WLDBIL::KILGOREBEAmer BillWed Apr 16 1997 11:206
    
.4> How do I monitor this PTR?
    
    Get a job at BEA Systems, Inc (a publicly traded company -- BEAS on
    NASDAQ). I can refer you...
2468.6LEMAN::DONALDSONFroggisattva! Froggisattva!Wed Apr 23 1997 08:2619
By the way...

We also ran into the _narrow problem (we use the external
typecodes and I cant see how else you can work with a
complex project).

We now generate a file with empty _narrow routines for *all*
our object types. This permits us to link just the stubs
and dispatchers we want and leave out all the rest.
(We specify the narrows.lib as a library).

If we dont do this, using one part of the object model
pulls in *everything*.

We even have trace in the nil narrows which says 
"You're using the xxx nil _narrow - use the correct one"
in case they are mistakenly called.

John D.