Implement DynamicSet<T>, DynamicMap<T> to provide bindings in Guice
The core server can now declare that it needs a DynamicSet supplied by
Guice at runtime:
DynamicSet.setOf(binder(), SomeBaseType.class);
and then receive this as an injection:
DynamicSet<SomeBaseType> theThings
Core server code can register static implementations into this set:
DynamicSet.bind(binder(), SomeBaseType.class).to(AnImpl.class);
Plugins may use the same syntax in their own Guice modules to register
their own implementations. When a plugin starts, its registrations
will be added to the DynamicSet, and when it stops, the references get
cleaned up automatically. During a hot reload of a plugin references
from the old plugin and the new plugin are matched up by collection
member type and Guice annotation information, and atomically swapped.
Plugins can use automatic registration if interfaces are annotated
with @ExtensionPoint and the plugin implementation is annoated with
@Listen and also implements the interface, directly or indirectly
through its base classes or interfaces:
(gerrit-extension-api)
@ExtensionPoint
public interface NewChangeListener {
(gerrit-server)
DynamicSet.setOf(binder(), NewChangeListener.class);
(plugin or extension code)
@Listen
class OnNewChange implements NewChangeListener {
Automatic registration binds the listeners into the system module,
which may prevent plugins or extensions from automatically connecting
with extension points inside of the HTTP or SSH servers. This
shouldn't generally be a problem as the majority of interfaces plugins
or extensions care about will be defined in the core server, and thus
be in the system module.
Change-Id: Ic8f371d97f8f0ddb6cad97fef3b58e1c3d32381f
11 files changed
