| com.jcorporate.expresso.kernel.ComponentLifecycle
All known Subclasses: com.jcorporate.expresso.core.cache.DefaultCacheManager, com.jcorporate.expresso.core.dbobj.Schema, com.jcorporate.expresso.core.dataobjects.PersistenceManager, com.jcorporate.expresso.kernel.test.TestComponent, com.jcorporate.expresso.kernel.management.DefaultServiceWriter, com.jcorporate.expresso.core.dataobjects.jdbc.JdbcPersistenceManager, com.jcorporate.expresso.core.security.CryptoManager, com.jcorporate.expresso.core.db.TypeMapper, com.jcorporate.expresso.core.db.config.JNDIConfig, com.jcorporate.expresso.core.db.DBConfig, com.jcorporate.expresso.kernel.DataContext,
| ComponentLifecycle | | public interface ComponentLifecycle (Code) | | 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.
author:
Michael Rimov |
| Method Summary | |
| public void | configure(Configuration newConfig)
Configure the service. | | public void | destroy()
Called upon destruction of the service. | | public void | initialize()
Initialize the component, this is called before the component receives
any configuration information. | | public void | reconfigure(Configuration newConfig)
Reconfigures the service during runtime without having to restart the
container.
Reconfigure is done this way vs. |
| configure | | public void configure(Configuration newConfig) throws ConfigurationException(Code) | | 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 arenot what is expected by the Component
throws:
ConfigurationException - if for some reason the Component cannot copewith the configuration sent to it. If this exception is thrown then ZEROreconfiguration takes place. Configure() must be an all or nothing 'transaction' |
| destroy | | public void destroy()(Code) | | Called upon destruction of the service. This may or may not have anything
to do with container shutdown or reloading.
|
| initialize | | public void initialize()(Code) | | Initialize the component, this is called before the component receives
any configuration information.
|
| reconfigure | | public void reconfigure(Configuration newConfig) throws ConfigurationException(Code) | | 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 arenot what is expected by the Component
throws:
ConfigurationException - if for some reason the Component cannot copewith the configuration sent to it. If this exception is thrown then ZEROreconfiguration takes place. Configure() must be an all or nothing 'transaction' |
|
|