Trait RuntimePlugin

Source

pub trait RuntimePlugin:
    Debug
    + Send
    + Sync {
    // Provided methods
    fn order(&self) -> Order { ... }
    fn config(&self) -> Option<FrozenLayer> { ... }
    fn runtime_components(
        &self,
        current_components: &RuntimeComponentsBuilder,
    ) -> Cow<'_, RuntimeComponentsBuilder> { ... }
}

Expand description

Runtime plugin trait

A RuntimePlugin is the unit of configuration for augmenting the client with new behavior.

Runtime plugins can register interceptors, set runtime components, and modify configuration.

Provided Methods§

Source

fn order(&self) -> Order

Runtime plugin ordering.

There are two runtime plugin “levels” that run in the following order:

Service runtime plugins - runtime plugins that pertain to the entire service.
Operation runtime plugins - runtime plugins relevant only to a single operation.

This function is used to determine runtime plugin order within those levels. So regardless of this Order value, service runtime plugins will still always execute before operation runtime plugins. However, Defaults service runtime plugins will run before Overrides service runtime plugins.

Source

fn config(&self) -> Option<FrozenLayer>

Optionally returns additional config that should be added to the ConfigBag.

As a best practice, a frozen layer should be stored on the runtime plugin instance as a member, and then cloned upon return since that clone is cheap. Constructing a new Layer and freezing it will require a lot of allocations.

Source

fn runtime_components( &self, current_components: &RuntimeComponentsBuilder, ) -> Cow<'_, RuntimeComponentsBuilder>

Returns a RuntimeComponentsBuilder to incorporate into the final runtime components.

The order of runtime plugins determines which runtime components “win”. Components set by later runtime plugins will override those set by earlier runtime plugins.

If no runtime component changes are desired, just return an empty builder.

This method returns a Cow for flexibility. Some implementers may want to store the components builder as a member and return a reference to it, while others may need to create the builder every call. If possible, returning a reference is preferred for performance.

Components configured by previous runtime plugins are in the current_components argument, and can be used to create nested/wrapped components, such as a connector calling into an inner (customer provided) connector.