If the POACurrent object is resolved via the 
CORBA::ORB::resolve_initial_references() mechanism before the RootPOA object, 
a deadlock occurs.

Since the POACurrent object is only initialized when the RootPOA is first 
initialized (via TAO_Object_Adapter_Factory::create()), 
TAO_ORB_Core::poa_current() attempts to initialize the RootPOA if the cached 
POACurrent reference is nil.  That is done while holding the ORB Core's lock.  
When the RootPOA is initialized, the POACurrent object is also created and 
set/stored in the ORB Core.  However, setting the POACurrent object requires.  
Since the lock is still held, by the TAO_ORB_Core::poa_current() accessor, a 
deadlock occurs.

Several ways to potentially fix this problem include:

* Move the POACurrent initialization to the POA's ORBInitializer::pre_init() 
method, and register the POACurrent reference with the ORB via the 
ORBInitInfo::register_initial_reference() method.  Then, remove the 
TAO_ORB_Core::poa_current() accessor methods.  The TAO_OBJID_POACURRENT 
element would have to be removed from the TAO_LIST_OF_INITIAL_SERVICES 
macro/list in `tao/objectid.h' since the ORB::register_initial_references() 
mechanism is linked to the ORB::list_initial_services() mechanism.
   -- This is my first choice.

* Call orb_core->orb()->register_initial_reference() in the 
TAO_Object_Adapter_Factory::create() method, and remove the 
TAO_ORB_Core::poa_current() methods.
   -- This is my second choice.

* Temporarily release the lock via a reverse lock in the 
TAO_ORB_Core::poa_current() method just before the RootPOA is initialized.  
This is a hack that probably introduces subtle concurrency issues.

It's entirely possible that I'm missing something fundamental, but that's all 
I can think of right now.