Some ExplorerComponent implementations took other concrete implementations as constructor arguments. This caused the dependency injector to resolve these anew upon every invocation with a transient lifetime. We should always use interfaces (ie. ResultProvider<T>) in the constructor arguments for components to ensure the DI works as expected.
Wherever classes implemented two component interfaces, ResultProvider<T> and PublisherComponent, the DI treated these as separate invocations (despite the scoped lifetime) so there could be two (but no more 😅 ) of each of these components. Fixing this required some reflection magic during component registration to 'forward' the second registration to the first.
Fixes #236
There were actually two problems causing this:
ExplorerComponent
implementations took other concrete implementations as constructor arguments. This caused the dependency injector to resolve these anew upon every invocation with atransient
lifetime. We should always use interfaces (ie.ResultProvider<T>
) in the constructor arguments for components to ensure the DI works as expected.ResultProvider<T>
andPublisherComponent
, the DI treated these as separate invocations (despite thescoped
lifetime) so there could be two (but no more 😅 ) of each of these components. Fixing this required some reflection magic during component registration to 'forward' the second registration to the first.