When run by the acsdaemon, the Container would crash on startup because it was receiving an IOR instead of a corbaloc: string, which was used by the ACSCorba module to access ACS services directly.  After changing ACSCorba to direct its requests to the Manager, the Container was still crashing because no connection to the Manager was available.  Changing the order of initialization so that the connection to the Manager was made before any ACS service requests were attempted removed the failure.
When run by the acsdaemon, the Container would crash on startup because
it was receiving an IOR instead of a corbaloc: string, which was used
by the ACSCorba module to access ACS services directly.  After changing
ACSCorba to direct its requests to the Manager, the Container was still
crashing because no connection to the Manager was available.  Changing
the order of initialization so that the connection to the Manager was
made before any ACS service requests were attempted removed the failure.

If the Python component's CDB code information was incorrect, the
activate_component method would log the Python exception that caused
the fault.  This message gives no information to the user about what
the actual problem was without reading the Container source code.
An exception handler was added for the two Python exceptions that
are raised due to bad CDB information that raises ACSErrors with
more informative error messages.


git-svn-id: afcf11d89342f630bd950d18a70234a9e277d909@65355 523d945c-050c-4681-91ec-863ad3bb968a

ACS-Community/ACS,ACS-Community/ACS,jbarriosc/ACSUFRO,ACS-Community/ACS,ACS-Community/ACS,jbarriosc/ACSUFRO,ACS-Community/ACS,csrg-utfsm/acscb,csrg-utfsm/acscb,csrg-utfsm/acscb,jbarriosc/ACSUFRO,csrg-utfsm/acscb,jbarriosc/ACSUFRO,csrg-utfsm/acscb,ACS-Community/ACS,ACS-Community/ACS,csrg-utfsm/acscb,jbarriosc/ACSUFRO,ACS-Community/ACS,jbarriosc/ACSUFRO,csrg-utfsm/acscb,csrg-utfsm/acscb,jbarriosc/ACSUFRO,jbarriosc/ACSUFRO,jbarriosc/ACSUFRO