search

Beapi-io / spring-boot-starter-beapi

Springboot 'convention over config' starter for API Automation
Other
1 stars 1 forks source link

TASK : logger.devnotes #64

Closed orubel closed 1 year ago

orubel commented 1 year ago

BRILLIANT FEATURE!!!

give dev ability to run with logging value of 'devnotes' (much like INFO/WARN/DEBUG) so you can get 'developer notes on why a HTTP STATUS code may have occurred'

Better yet... rather than logging, can be emailed letting them know of error and possible solutions

Needs to be internationalized but this can avoid TONS of question and further automate platform and make easier to use.

elimelt commented 1 year ago

Regarding your statement on emailing logs, would an external email service be used, or is that something you'd like to implement internally and be optionally set up during configuration? Just curious!

orubel commented 1 year ago

The point behind the 'starter' is to provide a 'basic' tool that can be configured to your needs. We provide the tool, you configure how you want. So we will test to make sure it can work with a queue but it won't support any particular queue out of the box

Most likely it will just support emailing via a local smtp install at start (https://linuxhint.com/bash_script_send_email/)

And we don't want it to email 'logs'... just that a HTTP error code happened, where and what most likely 'caused the issue'. This is both to reduce issue with users & developers having to search through code to find the issue.

elimelt commented 1 year ago

Ah, that makes sense. Thanks!

orubel commented 1 year ago

This is actually very easy as the errors get thrown in specific places so we can easily tell why and what caused it and the chain of events leading up to that specific HTTP status error (in 90% of cases) at that location in the code.

Also, this requires a developer to run the program on the backend with this flag. So it is mostly for 'backend' testing/development and devops.

There probably won't be a massive call for hooking up message queues for this functionality; probably just a nice 'thank you' for making troubleshooting alot easier' :)

orubel commented 1 year ago

well since slf4j cannot have custom LEVELs, have to just use a MARKER.

Not the best solution but still provides great output for developers.

Am integrating to provide troubleshooting solutions for developers when using 'logger.info'

May want to integrate this at a less verbose level of logging

orubel commented 1 year ago

we can use WARN and then put these all under 'isWarnEnabled' (or not as it won't be called if we use log.warn)

log.info is too VERBOSE and log.error gets used in PROD. Log.warn should be perfect because practically no one uses it and we can declare it at a CLI

orubel commented 1 year ago

Implemented the beginnings of this. Should be a good start. Just need to run with '--warn'