-
-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add logging
feature with different logging handlers
#663
Comments
There was a However, having a We will likely add this feature later, but for now we won't have time to implement it for Masonite 4 (I would be glad to help on this if you want to contribute to it). |
Yes I also support this feature. We can add a few different handlers as we had before:
|
Can take a look at what masonite-logging had and replicate those features since that package was pretty complete for M3 |
logging
feature with different logging handlers
That Sounds great!. In the mean time I have added a basic LoggingProvider to my M4 project to include a catchall and configuration based on the context the logging is working in (AWS Lambda or local development) But yeah sounds like a great idea to reuse/tweak the M3 provider |
I also need this feature. Hope it gets integrated. |
Is your feature request related to a problem?
Kind of.
Currently there is no way to log any form of message (exceptions, errors or debug info to persistent storage for later evaluation.
This is a problem in production scenarios where you want to store the message for evaluation and bug reproduction/confirmation.
What do we currently have to do now?
There is no easy out of the box way to do this.
Describe the solution you'd like
Possibly a
LoggingProvider
that can register handler/sEach handler listens for (or processes only) specific log level messages in a specific way
eg
Each handler would receive the message as by the
logging
module (eg logging.info()).The handler would then process the message in whatever way is designed for.
ie send to a file, add a row in a db table, custom handler to send to an external service via api, etc.
This offers maximum flexibility and configuration for logging messages of any type regardless of environment or deployment strategy.
Describe alternatives you've considered
Is there something I have missed with this?
Would this be a breaking change ?
Anything else ?
No response
The text was updated successfully, but these errors were encountered: