Comments (8)
I could create a PR for a small logrus abstraction but would need help feeding it into the whole setup.
from ocpp-go.
A default logger interface could look something like this:
var Log Logger
type Logger interface {
Print(v ...interface{})
Printf(format string, v ...interface{})
Debug(v ...interface{})
Debugf(format string, v ...interface{})
Info(v ...interface{})
Infof(format string, v ...interface{})
Warn(v ...interface{})
Warnf(format string, v ...interface{})
Error(v ...interface{})
Errorf(format string, v ...interface{})
Fatal(v ...interface{})
Fatalf(format string, v ...interface{})
}
type Entry interface {
Logger
WithField(key, val string) Entry
WithFields(fields map[string]interface{}) Entry
}
One could add an init method to populate sirupsen/logrus by default or even leave it nil to avoid the dependency.
from ocpp-go.
Yes, that is a very good point.
I'd actually love an opinion on this one, since there is another imho valid approach, compared to the one you posted:
type Logger func(...interface{})
type FormattedLogger func(...interface{})
var debugLog Logger = nil
var formatLog FormattedLogger = nil
func SetLogger(logger Logger) {
debugLog = logger
}
func SetFormattedLogger(logger FormattedLogger) {
formatLog = logger
}
And an application would just have to hook it up like this:
ocpplog.SetLogger(logrus.Debug)
ocpplog.SetFormattedLogger(logrus.Debugf)
It's less flexible but very minimal, and does not require any further implementation.
What do you think?
from ocpp-go.
I'd honestly prefer a more minimal logging interface- the ability to differentiate from trace to fatal seems important though.
I'm not sure why you need two different ones?
Something like this would be somewhat minimal:
type Logger interface {
Print(v ...interface{})
Printf(format string, v ...interface{})
Debug(v ...interface{})
Debugf(format string, v ...interface{})
Info(v ...interface{})
Infof(format string, v ...interface{})
Warn(v ...interface{})
Warnf(format string, v ...interface{})
Error(v ...interface{})
Errorf(format string, v ...interface{})
Fatal(v ...interface{})
Fatalf(format string, v ...interface{})
}
You'd still need nil checks if the logger is not initialized or assign a nil implementation be default. Setting logging level might also be added.
See https://github.com/influxdata/influxdb-client-go/blob/master/log/logger.go for something I've contributed to.
from ocpp-go.
Well, the library itself should not really throw anything other than errors or debug information. There might be some more levels showing up right now, but that can be optimized.
Anyways, feel free to add your suggested solution. Do you want me to add you as a collaborator? So you can branch from here directly and I can help out adjusting the existing log statements.
from ocpp-go.
Imho you don't need
ocpplog.SetLogger(logrus.Debug)
ocpplog.SetFormattedLogger(logrus.Debugf)
It's usual for a logger to support the plain and formatted version afaiks.
Imho there are 3 reasons of logging (i.e. error handling in context of this library):
- synchronous errors - these should be returned, caller should handle (logging is handling)
- intermediate errors that can be retried internally - these might either be logged (need a logging abstraction then like log.Logger as interface) or communicated (need something like errorChan then). Note sure this case currently exists?
- errors from async operations. You could either make the operation synchronous and leave it to the caller to wrapp error handling inside a go func or return result using something like an errorChan or resultChan (or both). Any of these channels could also serve as indicator that the async operation has finished
Generic debug logging should probably not be part of the final library. If it's necessary it could be handled similar to 2.
from ocpp-go.
I'll make a suggestion for the core library.
from ocpp-go.
Suggestion is done, just added the websocket library as well. If this is the direction you want to go in I can see these points:
- validate ich client/server and websocket error handling should be connected
- validate if client/server error handler should be a richer type (struct something)
- update examples to use the error handler
- update readme
from ocpp-go.
Related Issues (20)
- Validator instance seperate in ocpp1.6 and ocpp2.0.1 HOT 1
- Unable to Include LocalAuthorizationList in OCPP1.6 SendLocalList Command HOT 2
- Infinite wait on stopping a disconnected charge point HOT 1
- Need to support panic recovery in the request handlers HOT 4
- Unhandled `FormatViolation` type on `CallError` on ocpp v2 (OCPP 2.0.1 Specification, Table B06.FR.17)
- Firmware Status Notification HOT 2
- Clustering - Horizontal Scaling, Production deployment more than one node HOT 2
- OCPP 2.0 Reset Request Validator Error HOT 2
- OCPP2.0.1 No means for cleanly sending securityerror codes HOT 1
- Unhandled/error validation for `TransactionEventRequest` eventType:`Started` with idToken/IdTokenType (type:`NoAuthorization` and empty `idtoken` value)
- Race condition in chargePoint.Start() HOT 4
- Race in library and tests HOT 1
- Unhandled json errors in GetConfiguration HOT 3
- Parsing of local timestamps not supported - spec violation? HOT 9
- Central-system 1.6 example - "fatal error: concurrent map writes" when connecting multiple chargers rapidly HOT 1
- Code Generation HOT 1
- TriggerMessage.Req validation disallows passing connector 0 HOT 6
- ChangeConfigurationRequest doesn't allow empty values
- Bad Request response for https via curl request HOT 1
- Release new version? HOT 2
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 ocpp-go.