This is my take on making the core ZipkinTracer independent from the IOwinContext - by make it dependent on the good ol'System.Web.HttpContext 😮.
The reason why we need this, because structure of the ZipkinTracer does not allow us to remove the dependency on some http context. By make it dependent on the HttpContext (and structuring the framework-dependent code - i.e. Owin, WebApi - to separate packages) we can have a core tracer which is dependent on the .NET Framework provided context only. At the same time, the framework dependent code will be able to retrofit the incoming requests to the HttpContext world on the fly (unfortunately though we won't be able to support self hosting Owin scenarios anymore as we need IIS to build our HttpContext).
Please note that this version does not introduce any new functionality but it has breaking changes, therefore we have to version it as the next major (v4.0.0) version.
@mdsol/team-51 Please review and merge.
@jcarres-mdsol @cabbott FYI
This is my take on making the core ZipkinTracer independent from the
IOwinContext
- by make it dependent on the good ol'System.Web.HttpContext
😮.The reason why we need this, because structure of the ZipkinTracer does not allow us to remove the dependency on some http context. By make it dependent on the
HttpContext
(and structuring the framework-dependent code - i.e. Owin, WebApi - to separate packages) we can have a core tracer which is dependent on the .NET Framework provided context only. At the same time, the framework dependent code will be able to retrofit the incoming requests to theHttpContext
world on the fly (unfortunately though we won't be able to support self hosting Owin scenarios anymore as we need IIS to build ourHttpContext
).Please note that this version does not introduce any new functionality but it has breaking changes, therefore we have to version it as the next major (v4.0.0) version.
@mdsol/team-51 Please review and merge. @jcarres-mdsol @cabbott FYI