Comments (7)
What if we had an internal "simple logger" and "deep logger", with the internals calling deep logger with an object and it deconstructing it and passing to the simple logger.
Then as a logging implementor you could choose which one you use....
Just pondering out loud here... thoughts ? @uglybugger
from nimbus.
Hmm... sounds like we'd be taking an implicit dependency on Serilog's format strings without an explicit reference to it. We may actually be better off taking an explicit dependency on Serilog and gracefully degrading to a string.Format(...) logger via a Serilog sink.
Still mulling over this one...
from nimbus.
I'm going to say it again.......
I don't want to take an explicit dependency on Serilog.
On Wed, Dec 18, 2013 at 3:03 PM, uglybugger [email protected]:
Hmm... sounds like we'd be taking an implicit dependency on Serilog's
format strings without an explicit reference to it. We may actually be
better off taking an explicit dependency on Serilog and gracefully
degrading to a string.Format(...) logger via a Serilog sink.Still mulling over this one...
—
Reply to this email directly or view it on GitHubhttps://github.com/DamianMac/Nimbus/issues/23#issuecomment-30817437
.
from nimbus.
Neither do I, hence "Still mulling over this one" - there must be a better way to keep it implementation-agnostic but also expose better-structured log messages.
I really don't want to be writing a Serilog-style parser or anything that strips out Serilog format strings and downsamples them to standard string.Format(...) ones - that's too far removed from the point of the project.
Hmm...
from nimbus.
What about a wrapper. I'm using this at the moment: https://gist.github.com/droyad/6649ce7377cfe57cef0f
from nimbus.
Hmm... That wrapper looks like it takes a low-priority concern and wraps the entire bus in it.
I wonder if we're solving the wrong problem here. If we want structured logging of what the bus itself is doing, I think we have enough. If the real problem we're solving is that we want structured logging of all the messages crossing the bus then we're probably better off implementing audit queues/topics sooner rather than later.
Thoughts?
from nimbus.
Closed in favour of #39. We're probably always going to want more internal logging but IMO it's better to consume the event stream if we want to have structured logging of the messages themselves - this way, we get access to the complete message content in its original form and can do with it what we wish.
from nimbus.
Related Issues (20)
- (Non-)reliable Azure/WSB messaging in V3 HOT 5
- MessageIds do not correlate between producers and subscribers HOT 1
- When does it really make sense to use a project like Nimbus vs Hangfire? HOT 1
- Question: Are there any plans on supporting creating partitioned azure queues? HOT 1
- Protobuf serializer needs to support NimbusMessage
- BusEventSender.Publish() swallowing exceptions - how does OutboundInterceptor.OnEventPublishingError work? HOT 1
- HeartBeat messages HOT 1
- Memory leak in Nimbus.Infrastructure.Dispatching.SubsequentDispatchContext HOT 1
- MessageLoggingExtensions throws exception on formatting output on any ILogger implementation HOT 2
- NuGet packages from myget.org only shows 50 latest versions HOT 1
- Incorrect expiry of RequestResponseCorrelationWrapper
- DendencyResolutionException: No registration for type Nimbus.Transports.WindowsServiceBus.Filtering.ISqlFilterExpressionGenerator
- Event subscription naming does not use fully-qualified handler type name HOT 9
- Porting Nimbus to Netstandard 2.0 (.NET Core & .NET 4.6.2) HOT 1
- Nimbus.Transports.WindowsServiceBus nuget package introduces FodyWeavers.xml file into target project
- Release dotnet core HOT 2
- AMQP Transport HOT 3
- Required permissions HOT 1
- Azure Service Bus subscriptions not reconnecting
- ASB: First time deployments of new subscriptions failing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nimbus.