When a component starts up, it gets its own
copy of its configuration object. That copy is managed by
the config interceptor. This means that altering a
config object by looking it up with the
calling setters on it will not affect the copy of
configuration used by the component.
The proper mechanism for altering the settings of a
running component are by utilizing the features of
its config interceptor. Through the magic of the
, you can directly cast a component to
its specific configuration implementation and make
updates to its configuration. Then you can make
cast the component to the
and make calls to apply the configuration.
Just setting the values of a component
configuration will not immediately alter the behavior
of the component. Internally, once you start altering
the configuration of a component, it actually creates
a working copy, rather than directly altering the
settings of the live component. The
method then causes the lifecycle action to pause calls
to the component while it reconfigures with the new
settings. This allows you to set many different properties
that may be interdependent as an atomic operation.
Here is an example of reconfiguring the ConnectionFactory
associated with a StatementFactory. This could be used
to swap between a test and live databases during runtime,
for database failover, etc.
// Lookup the component to reconfigure
StatementFactory statementFactory =
// Lookup the service you would like to set as the value
ConnectionFactory namedConnectionFactory =
// Register the new service with the component
// Have the component reconfigure itself to start using the new settings
You'll also notice the
method on the
. When called, that method will take the current
settings for the component and write them out to the configuration
service. This would be used to store the configurations for later use
(after restart). If not called, the file on disk will not be altered and
the component will revert to the original configuration after restart.