Where did/How to re-enable logging?

[eliezedeck]

I love logging which states which URL/resource has been accessed for each request. It's kind of gone with the goji/goji.

How to re-enable it?

[elithrar]

Hi Elie - are you referring to the github.com/zenazn/goji/web/middleware
package?

If so, it hasn't had an update for Goji v2 yet. I'm not sure if @zenazn has
plans to port it—if not I can take a look as it won't take long.

On Sun, 27 Dec 2015 at 1:22 PM, Elie Zedeck RANDRIAMIANDRIRAY <
notifications@github.com> wrote:

I love logging which states which URL/resource has been accessed for each
request It's kind of gone with the goji/goji

How to re-enable it?

—
Reply to this email directly or view it on GitHub
#11.

[eliezedeck]

@elithrar I guess so... It is not only useful, but it's also colorfully beautiful! :)

[zenazn]

I'm probably not going to have time to port it, at least not in the near term. Happy to have one of you take a shot at it!

[elithrar]

Through the magic of copy+paste and s/web.C/context.Context/g I've pulled together a Goji v2 package that covers the old:

• middleware.Logger
• middleware.RequestID (the logger uses this when available)
• Associated ResponseWriter wrappers from the web/mutil package and middleware/terminal.go that the middleware above used.

You can find it here: https://github.com/elithrar/goji-logger - if @zenazn can provide a goji/logger repo I can push it there instead (feel free to copy the package desc. from my repo).

It needs tests, but the guts are the same as the existing functions, so they should work as-is.

[basvanbeek]

Talking about loggers. Would like the ability to define alternative loggers especially since libraries like Goji are just a part of an app in a larger context.

[elithrar]

@basvanbeek Unless I'm misunderstanding what you mean: you can use any logging package you like right now.

[basvanbeek]

@elithrar The previous version of Goji had certain logging hardcoded inside it's internal functions. In case that would appear again in this library I'd like that to be calling an interface with the option to take an implementation of it by the user instead of calling the "log" package directly. If not than we're already ok as I typically envision logging in middleware and don't care too much about the rest.

What I do not like is diverting stdout and stderr generically and seeing all kinds of differently structured data appear from various libraries.

[zenazn]

Luckily for you, that's not going to happen again—I took great care to avoid that this time :)

It's possible that auxiliary packages in the Goji ecosystem will need loggers in the future, and standardizing on an interface there would almost certainly be useful, but that seems largely orthogonal to Goji (i.e., we should make an attempt to standardize that in the Go ecosystem at large, and not just for Goji)

[zenazn]

I'm going to close this issue, since it looks like @elithrar has largely addressed the OP's question.

I do still think it would be valuable for someone to experiment with a standard logging interface, and a compelling enough one would certainly find a lot of value in the Goji ecosystem and elsewhere, but I don't think Goji core will ever privilege one logger over any other.