[omniORB] BOA -> POA questions

[Stefan Seefeld]

David Riddoch wrote:

> > I find a call to myecho->_remove_ref() which I don't understand.
> > Given that the call to _this() increments the ref counter and sets it
> > to 1, I would think that a call to 'deactivate_object' sets it back to
> > 0, resulting in the deletion.
> 
> When a servant is created it has a reference count of 1.  When you
> activate it, it becomes 2.  You then call _remove_ref() to take it back to
> 1.  When you deactivate the servant, it will go to zero and be deleted
> (once all outstanding requests have completed).

I see ! I didn't find any mention of that behavior in H&V's book.
May be you should point that out clearly somewhere, I guess this kind of
question might come up again...

> > PS: is the Servant::_PD_repoId member portable ? I couldn't find any
> >     mention of how to access the repoId from a given interface C++
> >     type...
> 
> Do you mean foo::_PD_repoId (there is no Servant::_PD_repoId as far as I
> know)?  Anyway, it is non-portable.  The spec gives no way to get at the
> repo id, you are expected to generate them yourself I guess.

yes, I mean <Servant>::_PD_repoId with <Servant> being whatever interface
you declare.
That's pretty bad that there is no such standard way to access it. It would
fit in there the same way you have the <Servant>::_ptr_type and <Servant>::_var_type,
i.e. it would make it convenient to write templates which need the repoId,
such as 

template <typename T>
typename T::_ptr_type resolve_name(CosNaming::NamingContext_ptr context) 

which now needs a (redundant) second parameter which could in practice 
be deduced from <T>

Regards,	Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...