Uncentralized output makes integration complicated

[awfm9]

One thing I never understood and was hoping to see fixed in version 3 was the usage of different output streams. I don't quite understand the rationale, maybe someone can elaborate? Why do we have three different output sources, stdLogger, Color and HTTPErrorLogger?

In our use case, we really fit echo into microservices for those that expose a REST API, but the rest of the microservices use the same framework. This means that echo should submit to our architecture, not the other way around. This works great in most cases, but is a bit painful for logging. At this point, we work around it like this:

log := ourown.NewLogger()

server := echo.New()
server.Logger.SetOutput(ioutil.Discard)
server.Color.SetOutput(ioutil.Discard)
server.HTTPErrorHandler = custom.Error
server.Use(custom.Logger(log))

I see the point of potentially having different logs for requests and the rest of the messages, but I think there should be at most two output streams, where one of them can easily capture everything, and another one might just go to the HTTP clients as the responses.

[vishr]

We can expose SetOutput to control output for logger and color. HTTPErrorHandler anyways uses logger and sends output as HTTP response.

Let me know your thoughts.

/cc @Anon-Penguin

[mathvav]

I think the biggest thing is that both color and logger can send output to the terminal. If color didn't have the ability to directly output (you only could do logger.Fatal(color.Red("not enough caffeine"))), I feel like it'd be a lot less confusing (leaving the color object there to easily disable).

Scanning through the code, the color package is only used once to actually send the output to the terminal (vs just returning a colored string). But, others may use it more and I don't know if it's worth a breaking (however tiny) API change.

For v4, would it be worth it to wrap the color class without the extras to keep the API clean?

---

My Setup (just if you're interested)

I have to admit that I also use my own custom logging framework that deduces the caller function/line to help with debugging (not very resource intensive because I am conservative on what I log). Here's my setup:

var (
	engine = func() *echo.Echo {
		a := echo.New()
		a.Debug = globals.Debugging
		a.ShutdownTimeout = timeout
		a.Logger.SetPrefix("[ECHO] ")

		c := color.New()
		c.Disable()
		c.SetOutput(ioutil.Discard) // I got annoyed with the " ⇛ http server started on" messages not lining up with the rest of the output hehe; that message is the only thing piped through color
		a.Color = c

                // Lots and lots of pretty middleware goes here

		return a
	}()
)

(If you're wondering why I have this outside of a function: to make it easy to split files, I use as many init() functions as I need. One route = one init() function. Go guarantees that the execution order is var x type declarations outside functions > init() functions > main().)

Then, I just call my own library.

[djui]

I agree with @Anon-Penguin that the sparse use of Color (for this one line) seems like we have two options:

A. Replace the message with a log message (and if desired let the default Echo logger allow colours etc. to be logged)
B. Move that message up to the caller, which would be a cmd/myapp/main.go place.

I prefer (B) as this particular message does not know any internals that an external caller would not know (like PORT etc). It also decreases the external dependencies for Echo.

I think giving access to the Output is feels counter-intuitive as if that change is desired, one could already just pick their own logger and set the Output there. So: I don't want to be able to write a coloured log message to /dev/null, I want that this message is not required to be written.