-
Notifications
You must be signed in to change notification settings - Fork 257
Architecture
This document describes some of the core aspects of the Togglz architecture.
The core class of Togglz is the FeatureManager. There must be exactly one
instance for an application. There is an SPI called FeatureManagerProvider
which is responsible for looking up the "current instance" to use for the
application. So whenever you use FeatureContext.getFeatureManager(), this
SPI will be used to locate the FeatureManager.
There are two ways of managing the life cycle of the feature manager.
- Togglz managed FeatureManager
- Application managed FeatureManager
In this mode Togglz will create an instance of the FeatureManager and manage
its life cycle. In the early versions of Togglz this mode was the only mode
supported.
Please note that this mode is only supported if you include togglz-servlet
module in your project.
To tell Togglz how to configure the FeatureManager, users have to either
implement TogglzConfig or TogglzBootstrap. The latter one was added
latter and provides more control when creating the manager.
Togglz will try to locate implementations of TogglzConfig or TogglzBootstrap
using the BeanFinder SPI. This SPI basically allows Togglz to look up beans
managed by some application container (like Spring, CDI, Guice) by their type.
This mode has been added in a later version of Togglz. The basic idea is to let
the application manage the life cycle of the FeatureManager itself. So, if your
application uses Spring for example, you could configure the FeatureManager
in your beans.xml and the FeatureManager would end up being a standard Spring
bean. If you use Togglz this way, Togglz will effectively use
BeanFinderFeatureManagerProvider to lookup the BeanManager. This means that
The bootstrapping process of Togglz is triggered by TogglzFilter.
First, the filter tries to auto-detect which of the two modes, of managing the
FeatureManager, the application wants to use. It does so by testing if any of the
FeatureManagerProvider implementations provides a FeatureManager. If so, the
bootstrapping process is stopped, because FeatureContext will be able
to resolve the manager correctly.
If no existing FeatureManager can be found, Togglz will use
FeatureManagerBootstrapper to create a FeatureManager itself. This class
will use the BeanFinder SPI to find the configuration classes (TogglzConfig
or TogglzBootstrap) and use it configure the manager. The manager will then
be registered with the ContextClassLoaderFeatureManagerProvider which means
that after this bootstrapping process this particular FeatureManagerProvider
will be able to resolve the manager.
This auto-detection should work find in practice. However, you can set the
Servlet context attribute org.togglz.FEATURE_MANAGER_PROVIDED to bypass
the auto-detection. If this attribute is set to true, Togglz will assume
that the application manages the FeatureManager.