omniORB2 compliance

[Sai-Lai Lo]

Hi Daniel,

You are right in pointing out that the CORBA 2.0 specification offers very
little information on the server side code. There is no definitive
statement on whether it is compliant to use the pointer to the
implementation object directly to obtain the object reference.

The Portable Object Adaptor (POA) specs. is more clear on this. It says:

18.2.1

 "In several existing ORB implementations, each skeleton class derives from
 the corresponding interface class. ... These systems therefore allow an
 object reference for a servant to be implicitly obtained via normal C++
 derived-to-base conversion rules:
      MyImplOfA my_a;
      A_ptr     a = &my_a;
 Such code can be supported by a conforming ORB implementation, but it is
 not required, and is thus not portable. The equivalent portable code invokes
                   ^^^^^^^^^^^^^^^^^^^^
 _this() on the implementation object.."


For the sake of portability, we do not recommend the use of implicit
conversion with omniORB.

I should also point out that the code:

>    foo_impl *f = new foo_impl();
>    foo_ptr my_f = f->_this();
>    boa-> obj_is_ready(my_f);
>    CORBA::release(my_f);

although correct *does not* work in 2.[2,4,5]. Please use _obj_is_ready()
to register the implementation instead.

Regards,

Sai-Lai


>>>>> Daniel Popowich writes:

> I have a question about omniORB2 compliance which I'm hoping you can
> take a few moments to answer.

> In your recent documentation for release 2.4 you state:


>    foo_impl *f = new foo_impl();

>    f-> _obj_is_ready(boa);

> is omniORB2 specific and that accomplishing the same thing with
> compliant code would be as follows:

>    foo_impl *f = new foo_impl();

>    foo_ptr my_f = f->_this();
>    boa-> obj_is_ready(my_f);
>    CORBA::release(my_f);


> My question is, why is not the following compliant:


>    foo_impl *f = new foo_impl();

>    boa-> obj_is_ready(f);


> (In fact, this is exactly how you implement the inline method
> _obj_is_ready() generated for the skeleton classes!!)

> The OMG 2.1 documentation does not offer many details about
> implementing server side code.  Clearly, for clients the only
> references you should use are via T_ptr and T_var handles, but the
> standard is very unclear about the server side.  Is it non-compliant
> to use the pointer to the implementation object directly within your
> server code?

> For example, in some of my servers, I kick off a thread with access to
> my implementation object before calling boa->impl_is_ready().  As in:

>     // from a shared header
>     extern foo_impl *f;

>     // from my main() source
>     foo_impl *f;

>     int main(int argc, char *argv[])
>     {

>       // init orb and boa

>       f = new foo_impl();
>       boa-> obj_is_ready(f);

>       // kick off thread that uses 'f'

>       boa-> impl_is_ready(0, 1);

>       // wait for my thread

>       boa-> dispose(f);

>       ...

>     }


> Is this non-compliant?  Should I be creating a foo_ptr (via
> f-> _this()) and using that within my server code?  I can not find
> anything that states this in OMG documentation, but clearly your
> documentation indicates (rather strongly) I should be doing this.  On
> what do you base your statements?  Because it is clear from OMG
> documentation that any instance of an implementation class inheriting
> from a skeleton class is an Object_ptr, so why shouldn't I use that
> pointer?

> Thank you for your time and help.

> -------------------------------------------------------------------
> Daniel Popowich                  email: popowich@sovereign-hill.com
> Sovereign Hill Software, Inc.    phone:              (413) 587-2228
> 100 Venture Way                    fax:              (413) 587-2246
> Hadley, Massachusetts 01035   
> -------------------------------------------------------------------