Proposal: env["rack.logger"]

[Yehuda Katz]

I'd like to suggest that a standard Ruby logger object be found in env["rack.logger"].

This logger object should support:

logger.info

logger.debug

logger.warn

logger.error

logger.fatal

each of these objects should be able to take a block for deferred logging:

logger.info { some_expensive_operation (wont_be_run_in_warn_mode) }

We already do the latter in Merb (to skip expensive param processing in production mode) and will be adding it to Rails as well -- it'd be nice to standardize on it.

Thoughts?

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

[Scytrin dai Kinthra]

I have been implementing a similar feature in quite a few of the stacks I've been setting up, and it'd be nice to have a standard in the spec.
I would prefer we take the duck typing approach to the entry rather than the type restraint, as long as the object supports the 5 methods (and possibly #level for introspective purposes) it would be a valid rack.logger value.

stadik.net

[Joshua Peek]

+1

We should require servers to set a default logger so its *always*
available. Then Rails or other middleware down the stack can swap it
out with something else.

--
Joshua Peek

[Daniel N]

+1 from me.  I like it. 

[Scytrin dai Kinthra]

I would argue against a formal logger being required, but generating a default of a wrapper around rack.error seems sufficient enough a default.

--
stadik.net

[Joshua Peek]

On Mon, Jul 27, 2009 at 4:27 PM, Scytrin dai Kinthra<scy...@gmail.com> wrote:
> I would argue against a formal logger being required, but generating a
> default of a wrapper around rack.error seems sufficient enough a default.

Thats a good idea.

I just want something to be in rack.logger so we don't have to nil
check and you can count on your message going somewhere.

--
Joshua Peek

[Yehuda Katz]

On Mon, Jul 27, 2009 at 2:27 PM, Scytrin dai Kinthra <scy...@gmail.com> wrote:

I would argue against a formal logger being required, but generating a default of a wrapper around rack.error seems sufficient enough a default.

Yep. That was the thrust of my proposal :)

-- Yehuda

 

--
stadik.net

On Jul 27, 2009 1:07 PM, "Joshua Peek" <jo...@joshpeek.com> wrote:


+1

We should require servers to set a default logger so its *always*
available. Then Rails or other middleware down the stack can swap it
out with something else.


--
Joshua Peek

[Joshua Peek]

Waiting on comments from Chris.

Created a lighthouse ticket for this thread:
http://rack.lighthouseapp.com/projects/22435-rack/tickets/63-logger-spec

[Christian Neukirchen]

Joshua Peek <jo...@joshpeek.com> writes:

+1, For 1.1

--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org

[James Tucker]

On 3 Aug 2009, at 23:17, Christian Neukirchen wrote:

>
> Joshua Peek <jo...@joshpeek.com> writes:
>
>> On Mon, Jul 27, 2009 at 4:27 PM, Scytrin dai Kinthra<scy...@gmail.com
>> > wrote:
>>> I would argue against a formal logger being required, but
>>> generating a
>>> default of a wrapper around rack.error seems sufficient enough a
>>> default.
>>
>> Thats a good idea.
>>
>> I just want something to be in rack.logger so we don't have to nil
>> check and you can count on your message going somewhere.

+1, however, I would request please that some form of Null / No-Op
logger is available in core for profile testing (IO sucks).

The 'deferred' spec I find harder to agree with off the bat, as I
think it needs to be registered somewhere in the stack, or heavily
coupled.

I have some questions, as a result (particularly to Yehuda):

* Who implements the scheduling?
* Who implements the running?
* When is it run? (as per some spec definition)
* Does it have to be the same process?

I'd envisage something along the lines of:

l = Rack::SyncLogger.new
l.info { .. happens immediately .. }

l = Merb::Logger.new
l.info { .. happens after the request .. }

l = Rack::NullLogger.new
l.info { .. happens immediately or after request ? .. }

l = Rack::Logger.new # default?
l.info { .. happens when? .. }

Maybe some deferred logging middleware, but rack doesn't really have
this notion of "when done".

I could also be barking up the wrong tree, or maybe declarative is the
answer?

l = Merb::Logger.new
l.schedule { |item| Merb.after_response(item) }

?

[Jeremy Kemper]

Passing a block is a way of avoiding evaluating the argument when the
log level is higher, not a means to defer the logging itself.

I'd leave this "when is the block actually called?" behavior undefined.

jeremy

[Jeremy Kemper]

On Mon, Jul 27, 2009 at 2:27 PM, Scytrin dai Kinthra<scy...@gmail.com> wrote:
> I would argue against a formal logger being required, but generating a
> default of a wrapper around rack.error seems sufficient enough a default.

Who generates the default wrapper?

And if a middleware alters rack.errors, the default wrapper may break.
This is error prone.

jeremy

[Jeremy Kemper]

A little pushback: I dislike the trend of requiring more from the
environment for convenience. It's nice to rely on for a framework, but
it makes ad-hoc usage painful without an extra tool like MockRequest.

Having to tack on a superfluous { 'rack.input' => StringIO.new } was
bad enough. I feel like we're robbing Rack of some of its agility.

jeremy

[Yehuda Katz]

I tend to agree. I'd want the behavior to be defined if it exists, but I'm not comfortable pushing another requirement onto servers.

-- Yehuda

[Christian Neukirchen]

Jeremy Kemper <jer...@bitsweat.net> writes:

> I feel like we're robbing Rack of some of its agility.

A valid point that deserves more thought.

[James Tucker]

On 4 Aug 2009, at 00:55, Jeremy Kemper wrote:
> Passing a block is a way of avoiding evaluating the argument when the
> log level is higher, not a means to defer the logging itself.

Sorry, I was obviously mislead by the use of the term 'defer' in the OP.

> I'd leave this "when is the block actually called?" behavior
> undefined.

Defined by the logger itself then? That seems reasonable, as long as
there is some reasonable level of consistency in the implementations.