How to debug the rendering in Rails?

Hi,

I have some controller code like this:

def mailing_lists
@ml = MailingList.find_by_identifier(@params[:id])
@messages = @ml.messages
@headers["Content-Type"] = "application/atom+xml"
@response.headers['Last-Modified'] =

@messages.last.created_on.httpdateunless @
messages.empty?

minTime = Time.rfc2822(@request.env["HTTP_IF_MODIFIED_SINCE"]) 

rescue
nil
if minTime and @messages.first.created_on <= minTime
render :text => ‘Not Modified’, :status => 304
end
end

This works fine in development, but not in production. The funny thing
is
that tailing production.log I can see that http status code 200 or 304
is
returned, but in the apache access log I can see that 500 is returned.
The
latter is what I can also see in the browser.

I am wondering how to debug that… Putting rescues anywhere in the
above
mentionend code has no effect. So I guess it is in the render method
that is
called when no other explicit render invocation happend before?

I also don’t see anything I print with puts. In the dev environment
and
webrick I can see this output in the webrick console, but in production
(apache, fastcgi) I don’t know where to find this output. access.log,
error.log, production.log and the fastcgi logs don’t contain my puts
output.

Any ideas?

Cheers,
Mariano

On May 18, 2006, at 11:20 AM, Mariano K. wrote:

minTime = Time.rfc2822(@request.env["HTTP_IF_MODIFIED_SINCE"])  

rescue nil
if minTime and @ messages.first.created_on <= minTime
render :text => ‘Not Modified’, :status => 304
end
end

I don’t know how to answer your main question. However, in your code
above, isn’t the first line incorrect? Shouldn’t it be:

@ml = MailingList.find_by_identifier(params[:id]) # <-- notice no @
in front of params, it’s not a class instance var

Hi,

yes, that is ugly… I will clean that up.

Also for the use of @headers and of course @response.headers is also
not
nice to use. Still it is valid code.

So I am still looking how I can get some more debug output about the
rendering.

Cheers,
Mariano