com.jcorporate.expresso.kernel
Interface ComponentLifecycle

All Known Subinterfaces:

RootContainerInterface

All Known Implementing Classes:

CryptoManager, DataContext, DBConfig, DefaultCacheManager, DefaultServiceWriter, JdbcPersistenceManager, JNDIConfig, PersistenceManager, RootContainer, Schema, TestComponent, TypeMapper

public interface ComponentLifecycle

Lifecycle interface of an Expresso component. This should be implemented by any serious Expresso service that wishes to benefit from a component based architecture. Although there are other lifecycle events available in other interfaces, these are the basic lifecycle events that most components will utilize in one way or another.

Version:

$Revision: 1.4 $ on $Date: 2003/06/03 06:12:21 $

Author:

Michael Rimov

Method Summary

void	configure(Configuration newConfig) Configure the service.
void	destroy() Called upon destruction of the service.
void	initialize() Initialize the component, this is called before the component receives any configuration information.
void	reconfigure(Configuration newConfig) Reconfigures the service during runtime without having to restart the container.

Method Detail

initialize

public void initialize()

Initialize the component, this is called before the component receives any configuration information.

configure

public void configure(Configuration newConfig)
               throws ConfigurationException

Configure the service. This is where any parameter settings will take place.

Parameters:

newConfig - a read only dynabean containing all the needed configuration.

Throws:

IllegalArgumentException - newConfig is null or the types in it are not what is expected by the Component

ConfigurationException - if for some reason the Component cannot cope with the configuration sent to it. If this exception is thrown then ZERO reconfiguration takes place. Configure() must be an all or nothing 'transaction'

reconfigure

public void reconfigure(Configuration newConfig)
                 throws ConfigurationException

Reconfigures the service during runtime without having to restart the container.

Reconfigure is done this way vs. bean/property setters because sometimes components need special property setting orders and it is not easily possible to determine what order to set things in. This is the responsibility of the component

reConfigure() should be done in a transactional manner.... by that, we mean that if the reconfiguration fails, the component should revert to its previous state and continue operation

Parameters:

newConfig - a read only dynabean containing all the needed configuration.

Throws:

IllegalArgumentException - newConfig is null or the types in it are not what is expected by the Component

ConfigurationException - if for some reason the Component cannot cope with the configuration sent to it. If this exception is thrown then ZERO reconfiguration takes place. Configure() must be an all or nothing 'transaction'

destroy

public void destroy()

Called upon destruction of the service. This may or may not have anything to do with container shutdown or reloading.