Description
Support implementation of security plugins in separate crates and allow more complex initialization during plugin creation.
Motivation
The current architecture of the CDA runtime requires the type of the security plugin to be known at compile time, which limits our ability to support multiple implementations or to load the plugin dynamically. In fact, the only way I found to actually use a custom security plugin, was to copy and modify the complete cda-main crate. What I also find disadvantageous is the fact for each request a new instance of the security plugin is created via Default::default(). This may work, if creation of the instance is trivial, but might introduce quite some lag to request processing, if the plugin requires reading configuration from files or needs to invoke external services.
Proposed Solution
The proposed solution would be to create an instance of the plugin loader once before starting up the CDA server, thus allowing expensive initialization to be done once only.
Description
Support implementation of security plugins in separate crates and allow more complex initialization during plugin creation.
Motivation
The current architecture of the CDA runtime requires the type of the security plugin to be known at compile time, which limits our ability to support multiple implementations or to load the plugin dynamically. In fact, the only way I found to actually use a custom security plugin, was to copy and modify the complete cda-main crate. What I also find disadvantageous is the fact for each request a new instance of the security plugin is created via
Default::default(). This may work, if creation of the instance is trivial, but might introduce quite some lag to request processing, if the plugin requires reading configuration from files or needs to invoke external services.Proposed Solution
The proposed solution would be to create an instance of the plugin loader once before starting up the CDA server, thus allowing expensive initialization to be done once only.