diff options
Diffstat (limited to 'TAO/docs/poa_migration.html')
| -rw-r--r-- | TAO/docs/poa_migration.html | 44 |
1 files changed, 0 insertions, 44 deletions
diff --git a/TAO/docs/poa_migration.html b/TAO/docs/poa_migration.html deleted file mode 100644 index 220792a0241..00000000000 --- a/TAO/docs/poa_migration.html +++ /dev/null @@ -1,44 +0,0 @@ -Migrating from BOA to POA - -Client side: -<ul> -<li>Very little has changed, and some have not needed any changes.</li> -<li>You'll have to insure that the Makefile includes .o's for both the server -and client; this is necessary to support collocation.</li> -</ul> - -Server side: -<li>POA_init() is replaced with resolve_initial_references("RootPOA") followed -by a _narrow operation.</li -<li>The implementation no longer inherits from the client-side stub; they -inherit from PortableServer::ServantBase. The implications of this are (a) if -you want a object reference for that, you must use the _this() method.</li> -<li>Object ID's are assigned by the POA unless you activate the servant with a -specific ID; IDL_Cubit has examples on how to do this.</li> -<li>Unlike the BOA, the POA explicitly addresses the temporal nature of servants -and declares that a POA can service either transient or persistent servants -(not both). The root POA's (mandated, unchangeable) policy is "transient". -The implications of this are that in order for a client to be able to -manufacture an object reference on its own and use that to access an object, -the servant for that object must be registered with a POA whose policy is -"persistent". Thus, you must create a child POA with that policy and register -the servant with that POA. NOTE: when the POA declares something as -"persistent", it is only stating that the key is valid between different runs -of the server; it makes no claims that state or anything else is persistent.</li - -<ul> - <li> Servants are not automatically activated, hence you must register - them by calling some of the activate_object* methods on a POA or - calling _this() on the servant; with the latest you have no control on - the ObjectId (which sometimes is good), and the POA must support the - right policies (the RootPOA does).</li> - - <li>Servant constructors use to take a <const char*> parameter to set - they object id, this is not needed now, in fact in many cases they use - to pass this argument to the skeleton class: this will fail now.</li> -</ul> -This list is not intended to be exhaustive, but should give you a good -starting point. If you find things along the way which have to change and I -didn't note them, please send them to me. Perhaps we can work together on the -ultimate migration document. - |