damianh
commented
9 years ago I understand ILog DI scenarios when you want to control things like logger name etc from the out side. I occassionally do it in conjuction with static member field approach (the latter being much more common).
LibLog as it currently stands doesn't prevent you from doing this as it is - you can still DI ILogProvider and/or ILog around...
But if one only wants to DI logging stuff, then yes, let's explore a conditional compilation symbol.
I'm not in favour of a seperate LogProviders package though - I want to keep it single file & single package.
adamralph
Originally titled 'scriptcs use case'. After discussion, it seems there is a potential for a new feature here so I've updated the title accordingly.
Whether this is just an FYI, a discussion or a proposal for a feature I don't know, but I'm going to leave it here FWIW.
We are in the process of adopting LibLog for scriptcs (elbowing out Common.Logging).
The way logging has been done scriptcs historically is slightly different to most cases. Instead of using static log provision, i.e.
private static readonly ILog log = LogProvider.For<Foo>();etc, we inject logging types via constructors (currentlyILogbut we are taking advantage of the breaking change of removing Common.Logging to change toILogProvider). When using the core library, it is the responsibility of the consumer to pass anILogProviderinstance when constructing any objects which demand it. When using the hosting library, an IoC container is used to provide all the services required so anILogProvideronly needs to be passed once. (There is also an outstanding issue to remove this burden from consumers who don't care by providing an overload which uses a default logger internally.)The way we have adopted LibLog is to install it in our central Contracts library, which contains chiefly interfaces and some light abstract classes. It is the
ILogProviderinterface defined here which is used by all dependent libraries and indeed is the interface designed for consumption by script packs, modules and scripts when they demand an injected instance. I.e. it the officially supported interface for logging in scriptcs. Now, this does immediately couple the ecosystem to LibLog but, if the interfaces change in the future, we accept the burden of deciding whether to propagate the breaking change or hide/customise the LibLog interfaces as we see fit. For convenience, we also expose aDefautLogProviderwhich wraps the internal LibLog providers and aNullLogProvider.Now, the pros and cons of constructor vs static logging provision can be debated, but it does have the advantage that when a custom logger is specified, as indeed it is when the hosting lib is used from scriptcs.exe, there is no need to adapt and propagate the library specific
ILogProviderto the lower level libs. I did spike conversion of the whole thing to static log provision but I decided to abandon it since logging injection for script packs, modules and scripts is something we do want to support, so ultimately we will always end up doing this using centrally defined logging interaces in the Contracts library. Having each lib with it's own LibLog with all the adaptation required to get a provider all the way down into Contracts and the adaptation to get it back out as a Contracts interface just seemed like complete overkill.So, the bottom line is, for this use case, we hack out about 60 lines of LibLog to reduce the API to only that which is required to support it. You can see the change here https://github.com/adamralph/scriptcs/commit/2ee8d6916ccd2e9ab855a7517558995fd612d169
To summarise:
LogExtensionsstays public - the removal of the conditional comp there isn't strictly necessaryLogProviderbecomes internalLogProviderfields and methods are removedWhy am I raising this issue? Good question. I guess I'm looking for opinion on the above and/or a consideration of whether you'd like to support a conditional compilation symbol which could give us just the API required for this use case without having to customise LibLog after installation. I concede that it's likely few projects are using LibLog in this way, but I believe the approach of constructor based log provision, as opposed to static log provision, can be regarded as a general pattern.
</walloftext>