Investigate decoupling Wolverine from Lamar #728
Milestone
Comments
|
Honestly, right now this looks like the limitation might be "Lamar or the built in DI container". To use other containers, we'll need to possibly force Wolverine into a "stupid, service locator all the things" mode. I'm unenthusiastic. I'd rather have Wolverine be good with a limitation on IoC container choice than be possible to be mediocre with whatever else is out there. |
|
I would support a global setting in Wolverine to enforce DI (and basically make Lamar obsolete in this case). The result of enabling setting XY globally would be
Whether Lamar is still required then doesn't really matter to me. |
|
@Xzelsius I take pull requests. I'm deeply unenthusiastic. I get that you've got the awkward EF Core thing to contend with, but I'm not willing to disable Wolverine this way. |
Closed
jeremydmiller
added a commit
that referenced
this issue
Jun 28, 2024
…H-171 New ServiceDescriptor centric code generation First pass at the new ServiceDescriptor centric codegen Moved the codegen into the main projects Can declare that the source code gen cannot handle bi-directional dependencies. Yay. Tweaks on ArrayPlan First basic ArrayPlan usage, all existing tests are green More test cases covered Can handle open generics in codegen Big bang test harness for usage, first simplistic usage Spiked in ConstructorPlan Built out some of ServiceVariables and the ScopedLambdaPlan Seeded the ServiceCodeGen library & tests for local development. Will be temporary MOST of the tests are passing after replacing the Lamar backed DI service codegen deleting generated code before rebasing Spiked in usage of HostApplicationBuilder for Wolverine Upgraded to JasperFx.Core 1.6 Removed a usage of Lamar type scanning Few more helpers for ServiceContainer Renamed ServicePlanGraph to ServiceContainer QuickBuild convenience methods on ServicePlanGraph Adding a little more support into IServiceContainer.cs and getting the registration ready Wolverine internals mostly rely on IServiceContainer now Using ServiceContainer to determine handler method dependencies Removed *most* usage of Lamar in test code wip: more Lamar decoupling Removed more Lamar dependencies, using ServiceDescriptor type scanning Thinning down Lamar usings Bam, all service using codegen is *not* using Lamar. Moved the Wolverine API Endpoint provider to being its own extension Completely removed all references to Lamar in the MapWolverineEndpoints() call wip: switched over to built in ServiceProvider WIP: getting close with ServiceProvider All the persistence tests are passing All the HTTP tests are passing with ServiceProvider
jeremydmiller
added a commit
that referenced
this issue
Jul 1, 2024
…H-171 New ServiceDescriptor centric code generation First pass at the new ServiceDescriptor centric codegen Moved the codegen into the main projects Can declare that the source code gen cannot handle bi-directional dependencies. Yay. Tweaks on ArrayPlan First basic ArrayPlan usage, all existing tests are green More test cases covered Can handle open generics in codegen Big bang test harness for usage, first simplistic usage Spiked in ConstructorPlan Built out some of ServiceVariables and the ScopedLambdaPlan Seeded the ServiceCodeGen library & tests for local development. Will be temporary MOST of the tests are passing after replacing the Lamar backed DI service codegen deleting generated code before rebasing Spiked in usage of HostApplicationBuilder for Wolverine Upgraded to JasperFx.Core 1.6 Removed a usage of Lamar type scanning Few more helpers for ServiceContainer Renamed ServicePlanGraph to ServiceContainer QuickBuild convenience methods on ServicePlanGraph Adding a little more support into IServiceContainer.cs and getting the registration ready Wolverine internals mostly rely on IServiceContainer now Using ServiceContainer to determine handler method dependencies Removed *most* usage of Lamar in test code wip: more Lamar decoupling Removed more Lamar dependencies, using ServiceDescriptor type scanning Thinning down Lamar usings Bam, all service using codegen is *not* using Lamar. Moved the Wolverine API Endpoint provider to being its own extension Completely removed all references to Lamar in the MapWolverineEndpoints() call wip: switched over to built in ServiceProvider WIP: getting close with ServiceProvider All the persistence tests are passing All the HTTP tests are passing with ServiceProvider
jeremydmiller
added a commit
that referenced
this issue
Jul 7, 2024
…H-171 New ServiceDescriptor centric code generation First pass at the new ServiceDescriptor centric codegen Moved the codegen into the main projects Can declare that the source code gen cannot handle bi-directional dependencies. Yay. Tweaks on ArrayPlan First basic ArrayPlan usage, all existing tests are green More test cases covered Can handle open generics in codegen Big bang test harness for usage, first simplistic usage Spiked in ConstructorPlan Built out some of ServiceVariables and the ScopedLambdaPlan Seeded the ServiceCodeGen library & tests for local development. Will be temporary MOST of the tests are passing after replacing the Lamar backed DI service codegen deleting generated code before rebasing Spiked in usage of HostApplicationBuilder for Wolverine Upgraded to JasperFx.Core 1.6 Removed a usage of Lamar type scanning Few more helpers for ServiceContainer Renamed ServicePlanGraph to ServiceContainer QuickBuild convenience methods on ServicePlanGraph Adding a little more support into IServiceContainer.cs and getting the registration ready Wolverine internals mostly rely on IServiceContainer now Using ServiceContainer to determine handler method dependencies Removed *most* usage of Lamar in test code wip: more Lamar decoupling Removed more Lamar dependencies, using ServiceDescriptor type scanning Thinning down Lamar usings Bam, all service using codegen is *not* using Lamar. Moved the Wolverine API Endpoint provider to being its own extension Completely removed all references to Lamar in the MapWolverineEndpoints() call wip: switched over to built in ServiceProvider WIP: getting close with ServiceProvider All the persistence tests are passing All the HTTP tests are passing with ServiceProvider
jeremydmiller
added a commit
that referenced
this issue
Jul 7, 2024
…H-171 New ServiceDescriptor centric code generation First pass at the new ServiceDescriptor centric codegen Moved the codegen into the main projects Can declare that the source code gen cannot handle bi-directional dependencies. Yay. Tweaks on ArrayPlan First basic ArrayPlan usage, all existing tests are green More test cases covered Can handle open generics in codegen Big bang test harness for usage, first simplistic usage Spiked in ConstructorPlan Built out some of ServiceVariables and the ScopedLambdaPlan Seeded the ServiceCodeGen library & tests for local development. Will be temporary MOST of the tests are passing after replacing the Lamar backed DI service codegen deleting generated code before rebasing Spiked in usage of HostApplicationBuilder for Wolverine Upgraded to JasperFx.Core 1.6 Removed a usage of Lamar type scanning Few more helpers for ServiceContainer Renamed ServicePlanGraph to ServiceContainer QuickBuild convenience methods on ServicePlanGraph Adding a little more support into IServiceContainer.cs and getting the registration ready Wolverine internals mostly rely on IServiceContainer now Using ServiceContainer to determine handler method dependencies Removed *most* usage of Lamar in test code wip: more Lamar decoupling Removed more Lamar dependencies, using ServiceDescriptor type scanning Thinning down Lamar usings Bam, all service using codegen is *not* using Lamar. Moved the Wolverine API Endpoint provider to being its own extension Completely removed all references to Lamar in the MapWolverineEndpoints() call wip: switched over to built in ServiceProvider WIP: getting close with ServiceProvider All the persistence tests are passing All the HTTP tests are passing with ServiceProvider
|
This is complete in the 3.0 branch |
jeremydmiller
added a commit
that referenced
this issue
Aug 7, 2024
…H-171 New ServiceDescriptor centric code generation First pass at the new ServiceDescriptor centric codegen Moved the codegen into the main projects Can declare that the source code gen cannot handle bi-directional dependencies. Yay. Tweaks on ArrayPlan First basic ArrayPlan usage, all existing tests are green More test cases covered Can handle open generics in codegen Big bang test harness for usage, first simplistic usage Spiked in ConstructorPlan Built out some of ServiceVariables and the ScopedLambdaPlan Seeded the ServiceCodeGen library & tests for local development. Will be temporary MOST of the tests are passing after replacing the Lamar backed DI service codegen deleting generated code before rebasing Spiked in usage of HostApplicationBuilder for Wolverine Upgraded to JasperFx.Core 1.6 Removed a usage of Lamar type scanning Few more helpers for ServiceContainer Renamed ServicePlanGraph to ServiceContainer QuickBuild convenience methods on ServicePlanGraph Adding a little more support into IServiceContainer.cs and getting the registration ready Wolverine internals mostly rely on IServiceContainer now Using ServiceContainer to determine handler method dependencies Removed *most* usage of Lamar in test code wip: more Lamar decoupling Removed more Lamar dependencies, using ServiceDescriptor type scanning Thinning down Lamar usings Bam, all service using codegen is *not* using Lamar. Moved the Wolverine API Endpoint provider to being its own extension Completely removed all references to Lamar in the MapWolverineEndpoints() call wip: switched over to built in ServiceProvider WIP: getting close with ServiceProvider All the persistence tests are passing All the HTTP tests are passing with ServiceProvider
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ServiceCollectionThe text was updated successfully, but these errors were encountered: