Bug 2486

Summary:	Allow multiple ORBs in a process to have distinct configuration sets
Product:	TAO	Reporter:	Phil Mesnier <mesnierp>
Component:	ORB	Assignee:	Iliyan Jeliazkov <jeliazkov_i>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	jeff_mirwaisi
Priority:	P3
Version:	1.5
Hardware:	All
OS:	All

Description Phil Mesnier 2006-03-28 11:26:26 CST

Some ORB configuration is managed by factory objects loaded by the service
configurator. As such, things such as wait strategies are invariant across all
ORBs in an application.

This feature breaks resolves this by defining multiple service configuration
contexts. 

This feature is fully backwards compatible, a default service context is used by
any entities which do are not interested in the separation. Existing service
configuration interactions are made compatible with this feature by use of a
thread-specific context selector. 

More information will be added to this decription as it comes available.

Comment 1 Phil Mesnier 2006-03-28 11:26:47 CST

accepting

Comment 2 Iliyan Jeliazkov 2006-04-17 16:30:44 CDT

*** Bug 1459 has been marked as a duplicate of this bug. ***

Comment 3 Steve Totten 2006-07-04 11:07:38 CDT

Iliyan,

Would you add information to this bug such as that found in the ACE+TAO NEWS
files describing the new ACE_Service_Gestalt and related classes and the new
ORB-local configuration capabilities, then resolve this bug?

Thanks!
Steve

Comment 4 Chad Elliott 2007-04-03 07:22:46 CDT

Iliyan,

Can you address Steve's last comment and then close this bug?

Thanks,
Chad

Comment 5 Chad Elliott 2007-04-04 08:40:58 CDT

Added support for multiple independent Service Repositories through
configuration contexts called "Gestalt". Full backwards compatibility is
maintained through the existing ACE_Service_Config static methods, while direct
individual repository access is enabled through instances of the new
ACE_Service_Gestalt class. ACE_Service_Config has changed to a specialization of
ACE_Service_Gestalt and is only responsible for the process-wide configuration.

The motivation for these changes was to enable support for ORB-local Service
Objects. This for instance, makes it possible for differently configured ORBs to
coexist within the same proces.

In order to accomplish this, each orb (core) owns a "Gestalt", i.e. a service
object repository instance. There is also a process-wide, or "global" gestalt,
which is the default repository where service objects are registered. The latter
retains the interface and behavioral compatibility with any existing code. As a
consequence of this design choice, any un-named orb(s) will default to using the
ubergestalt, which is consistent with the prior behavior.