1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
The following TAO applications test and illustrate various Portable
Object Adapter (POA) interfaces and their usage scenarios.
. Identity
The example shows the identity between servants, ids,
and references.
. POA_Destruction
The program tests the destruction of a POA during an
upcall.
. Default_Servant
This program tests the behavior of
POA::id_to_servant() and POA::reference_to_servant()
with the use of default servants.
. Object_Reactivation
This program tests the reactivation of a servant that
has been deactivated but not removed from the Active
Object Map yet.
. Excessive_Object_Deactivations
This program tests for excessive deactivations of a
servant. The test checks excessive deactivations in a
POA with SYSTEM_ID and other POA with USER_ID. The
test also check for excessive deactivations during
upcalls.
. Non_Servant_Upcalls
This program check the users ability to make calls on
a POA during non-servant upcalls. In this example, a
servant which is being destroyed during because of a
deactivate_object() call, tries to deactivate another
object in its destructor.
. wait_for_completion
This program tests the <wait_for_completion> feature
of the POA.
. Single_Threaded_POA
This program tests to make sure that two threads
cannot call servants in a single threaded POA
simultaneously. At the same time, it makes sure that
a servant can call itself or other servants in the
same POA while in an upcall.
. Etherealization
This program tests for deactivation and
etherealization of reference counted and non reference
counted servants.
. Persistent_ID
This test checks the combination of PERSISTENT &
SYSTEM_ID POA policies.
. Policies
This program tests the construction of POA policies,
both through the generic ORB::create_policy interface
and the PortableServer specific interfaces.
. MT_Servant_Locator
This program tests that multiple calls to the Servant
Locator can take place simultaneously.
. Nested_Non_Servant_Upcalls
This program tests that nested non-servant upcalls are
handled correctly.
. POAManagerFactory
The program tests the POAManagerFactory interface. Test may
be run by hand using "POAManagerFactory -v" to get a verbose
report of individual tests being run.
. EndpointPolicy
Tests for the endpoint policy, the server listens on two
endpoints, one with an alias rendering it unreachable. The
server uses the endpoint policy to create two IORs, one with
the only the good endpoint and another with only the bad. The
client expects to reach the good ior and expects to fail with
the bad ior.
. RootPOA
This example explains how to obtain the name of the
RootPOA.
. NewPOA
This example explains the operations involved in
creation of new POAs.
. FindPOA
This example explains registering an adapter activator
for a POA and also the find_POA operation.
. Generic_Servant
A simple test interface is defined here and its
implementations, server and client programs are
available, which can be used for testing POA
applications. Several servers for that interface are
implemented using different POA policies; a common
client for all the servers is also provided.
. On_Demand_Activation
Contains programs that test the POA's 2 types of
activation of objects on demand, namely , Servant
Activator approach and Servant Locator , which depend
on the RETAIN/NON-RETAIN policy of a POA.
. Default_Servant
Contains a File IDL module and its implementation and
a server,client to test the File Module interfaces.
The System interface uses the USE_DEFAULT_MANAGER policy
to create a POA and registers a single File Descriptor
object as the default servant. The default servant serves
requests for many Descriptor objects.
. Explicit_Activation
This application explains various operations involved
in the explicit activation of objects; including the
creation of objects without servants (the servant is
created on demand).
. DSI
The client/server couple tests the DSI features of the
POA.
. Forwarding
The example is used to test the support for forwarding
in TAO. Three ways are shown: (a) Forwarding using
Servant Activators, (b) Forwarding using Servant
Locators, and (c) Forwarding using POA (this feature
is TAO specific).
. TIE
Shows off the standard TIE features of the new CORBA
2.2 specification.
. On_Demand_Loading
This example illustrates how to dynamically link and
load servants into a POA in a platform-independent
manner using the ACE_DLL feature and standard CORBA
Servant Manager features. In the example, the POA is
configured with the USE_SERVANT_MANAGER policy value,
which relies on an application supplied Servant
Manager object to supply object/server associations.
This example illustrates both Servant Activator and
Servant_Locator interfaces. The servant object is
created by a factory function that resides in a DLL
that is linked and loaded into the server's address
space on-demand when client requests arrive. The
ObjectID in each client request indicates which DLL
name and which factory function to use to create the
servant.
. Loader
This example is similar to the above except the id is
not hijacked to store the DLL and factory function
name. This information is provided to the Servant
Managers on creation.
. Explicit_Activation
This example is very similar to the
Explicit_Activation example except that the POAs are
deleted once the object references have been
created. After this, an adapter activator is install
in the RootPOA to reactivate the POAs on demand.
. Reference_Counted_Servant
This example shows how to use reference counted
servants to automatically manage dynamic memory for
servants.
|
