Main Page | Namespace List | Class Hierarchy | Alphabetical List | Class List | File List | Namespace Members | Class Members | File Members | Related Pages

alma::acs::container::ContainerServicesBase Interface Reference

Inheritance diagram for alma::acs::container::ContainerServicesBase:

Inheritance graph
[legend]
List of all members.

Public Member Functions

String getName ()
AcsLogger getLogger ()
DAL getCDB () throws AcsJContainerServicesEx
OffShoot activateOffShoot (Servant cbServant) throws AcsJContainerServicesEx
void deactivateOffShoot (Servant cbServant) throws AcsJContainerServicesEx
AdvancedContainerServices getAdvancedContainerServices ()
ThreadFactory getThreadFactory ()

Detailed Description

Through this interface, the container offers services to its hosted components. The component must call these methods explicitly; in this respect, ContainerServices is different from the other services that the container provides without the component implementation knowing about it. It can be thought of as a callback handle or a library.

Currently, methods are added to this interface as the functionality becomes available. At some point we will have to declutter the interface by introducing 2nd-level interfaces that harbor cohesive functionality. For example, instead of calling myContainerServices.getComponent(...), the new call will then be something like myContainerServices.communication().getComponent(...).

created on Oct 24, 2002 12:56:36 PM

Author:
hsommer


Member Function Documentation

OffShoot alma::acs::container::ContainerServicesBase::activateOffShoot Servant  cbServant  )  throws AcsJContainerServicesEx
 

Activates a CORBA servant that implements alma.ACS.OffShoot. The purpose of the OffShoot marker interface is to crack down on uncontrolled activation of just any CORBA services by Java components, while allowing this for selected subtypes of OffShoot, like alma.ACS.Callback.

The OffShoot servant can be either a subclass of the xyzPOA skeleton, or a xyzPOATie instance (delegation model). Since ACS 4.1.2, a tie servant is detected, and interception code gets inserted between the POATie skeleton and the offshoot implementation class. This way, the container can intercept (and log) calls to offshoots in the same way as it does for calls to components. It is therefore recommended to use the tie approach for all offshoot servants, unless there is a reason to avoid container interception.

Parameters:
cbServant the CORBA-generated servant, e.g. CBdoublePOA; must implement alma.ACS.OffShootOperations.
Returns:
needs a narrow-cast to the subtype, like CBdouble myCBdouble = alma.ACS.CBdoubleHelper.narrow(...).
Exceptions:
ContainerException if anything goes wrong, especially if cbServant is not an OffShoot.

Implemented in alma::acs::container::ContainerServicesImpl.

void alma::acs::container::ContainerServicesBase::deactivateOffShoot Servant  cbServant  )  throws AcsJContainerServicesEx
 

Deactivates the offshoot corba object. Caution: this method returns immediately, while the underlying org.omg.PortableServer.POAOperations#deactivate_object(byte[]) still works on the deactivation. If activateOffShoot(Servant) is called too shortly after deactivation, an exception will be thrown. TODO: find a remedy

Parameters:
cbServant must implement alma.ACS.OffShootOperations.
Exceptions:
AcsJContainerServicesEx if something goes wrong, e.g., if the offshoot servant was not active.

Implemented in alma::acs::container::ContainerServicesImpl.

AdvancedContainerServices alma::acs::container::ContainerServicesBase::getAdvancedContainerServices  ) 
 

More specialized methods are available from the AdvancedContainerServices.

Implemented in alma::acs::container::ContainerServicesImpl.

DAL alma::acs::container::ContainerServicesBase::getCDB  )  throws AcsJContainerServicesEx
 

Convenience method for accessing the Configuration Database.

Currently more than a convenience, given that the CDB is not yet a Java component, but a separate service...

Returns:
the CDB interface
Exceptions:
ContainerException 

Implemented in alma::acs::container::ContainerServicesImpl.

AcsLogger alma::acs::container::ContainerServicesBase::getLogger  ) 
 

Gets a Logger object that the component should use for logging.

The Logger will be set up with a namespace specific to the component that uses this ContainerServices instance.

Specific logger extensions that only apply to certain subsystems can be used by wrapping this logger with a class such as alma.acs.logging.domainspecific.AntennaContextLogger.

Returns:
Logger

Implemented in alma::acs::container::ContainerServicesImpl.

String alma::acs::container::ContainerServicesBase::getName  ) 
 

Delivers the unique instance name for the component. The name must have been specified at deployment time in the CDB (for static components like the famous "LAMP1" example), or must have been given to the manager at runtime by the client who creates a dynamic component (or was invented by the manager if none was given).

Returns:
the unique component instance name

Implemented in alma::acs::container::ContainerServicesImpl.

ThreadFactory alma::acs::container::ContainerServicesBase::getThreadFactory  ) 
 

Gets a ThreadFactory, to be used as input for other classes from the concurrent library (such as ThreadPoolExecutor), or simply to create new Threads.

All user-created threads should come from the factory returned here, so "<code>new Thread(...)</code>" should not appear anywhere in component code.

The returned thread factory creates new threads configured to run well in the container environment, e.g.

  • all threads are daeemon threads so that they can't interfere with container shutdown.
  • the priority is the same as that of the calling component thread (which is created by the ORB)
  • uncaught user exceptions are logged as WARNING before the thread terminates.
  • when a component is removed from the container, surviving user threads created by that component are killed using Thread#stop() (which even though deprecated, seems like the perfect choice in this particular situation). Otherwise a faulty components could permanently take away resources from a running container and from the other components.
Returns:
the thread factory to be used by the component to create new threads.

Implemented in alma::acs::container::ContainerServicesImpl.


The documentation for this interface was generated from the following file:
Generated on Thu Apr 30 02:52:23 2009 for ACS Java API by doxygen 1.3.8