[omniORB] starting nameservice within a server

[John D Heintz]

The reason I would use such a facility is to simplify unit testing.  Not=20
impossible to do otherwise, just easier is all.

John

On Wednesday 24 October 2001 05:52, Duncan Grisby wrote:
> On Tuesday 23 October, Matthias Hilmer wrote:
> > i know that TAO provides a class (TAO_Naming_Server) that allows me t=
o
> > start the naming service from within the server (as a thread).
>
> Why would you want to do that?  Is there any advantage over forking a
> new process for it?  I suppose there will be a bit of a performance
> gain, but if you're hitting the naming service hard enough for it to
> matter, you probably shouldn't be.
>
> > 1. is there any equivalent to this in omniorb? (i found nothing)
>
> No.
>
> > 2. if not, is it save to put the main line of omniNames.cc in a run
> > method of a class derived from omni_thread (naive spoken).
>
> It depends. As long as you start the naming service before you
> initialise the ORB anywhere else, you should be OK. omniNames forces
> the use of a particular port number, which can only be done before
> ORB_init(). If you do need to start the omniNames bits after
> ORB_init(), it won't be too hard to modify the necessary bits so it
> works.
>
> Depending on what you are doing, you may encounter a licensing
> problem with linking in omniNames. omniNames, like the other
> applications in the omniORB distribution, is licensed under the GPL,
> rather than the LGPL. That means that any of your code linked against
> omniNames would have to be licensed under the GPL too if it was ever
> released. It's not an issue if your application is only for use within
> your organisation.
>
> Cheers,
>
> Duncan.

--=20
=2E . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz@isogen.com

w w w . d a t a c h a n n e l . c o m