Proposal: env["rack.logger"]

139 views
Skip to first unread message

Yehuda Katz

unread,
Jul 27, 2009, 3:11:39 PM7/27/09
to rack-devel
I'd like to suggest that a standard Ruby logger object be found in env["rack.logger"].

This logger object should support:

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

unread,
Jul 27, 2009, 3:49:18 PM7/27/09
to rack-...@googlegroups.com

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

unread,
Jul 27, 2009, 4:02:36 PM7/27/09
to rack-...@googlegroups.com
+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

unread,
Jul 27, 2009, 5:14:47 PM7/27/09
to rack-...@googlegroups.com
+1 from me.  I like it. 

Scytrin dai Kinthra

unread,
Jul 27, 2009, 5:27:03 PM7/27/09
to rack-...@googlegroups.com

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

unread,
Jul 27, 2009, 5:30:08 PM7/27/09
to rack-...@googlegroups.com
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

unread,
Jul 27, 2009, 5:39:26 PM7/27/09
to rack-...@googlegroups.com
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

unread,
Aug 3, 2009, 12:27:59 PM8/3/09
to Rack Development
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

unread,
Aug 3, 2009, 6:17:38 PM8/3/09
to rack-...@googlegroups.com
Joshua Peek <jo...@joshpeek.com> writes:

+1, For 1.1

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

James Tucker

unread,
Aug 3, 2009, 7:21:35 PM8/3/09
to rack-...@googlegroups.com

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

unread,
Aug 3, 2009, 7:55:31 PM8/3/09
to rack-...@googlegroups.com

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

unread,
Aug 3, 2009, 7:57:12 PM8/3/09
to rack-...@googlegroups.com
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

unread,
Aug 3, 2009, 8:02:01 PM8/3/09
to rack-...@googlegroups.com

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

unread,
Aug 3, 2009, 8:23:54 PM8/3/09
to rack-...@googlegroups.com
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

unread,
Aug 3, 2009, 9:16:42 PM8/3/09
to rack-...@googlegroups.com
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

unread,
Aug 4, 2009, 4:21:33 AM8/4/09
to rack-...@googlegroups.com

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.

Reply all
Reply to author
Forward
0 new messages