Upgraded to 1.2 and my controllers are lost!


I upgraded to 1.2 and now my app says the following whenever I go to one of my controllers:

Expected script/../config/../app/controllers/home_controller.rb to define HomeController

But the first line of home_controller.rb is:

class HomeController < ApplicationController

This happens running under webrick as well as on the production environment (fastcgi).

$ rails -v Rails 1.2.1

I did the rake rails:update trick. It only seemed to change my boot.rb


Mike Vargo

Hi Mike, did you update your environment.rb file to use Rails 1.2.1 before performing

rake rails:update


Thanks for the help. The note about the engines plugin is scary. Not sure how to update...

As for Conrads question: Yes. In environment.rb

# Specifies gem version of Rails to use when vendor/rails is not present RAILS_GEM_VERSION = '1.2.1'

the rake rails:update touches the boot.rb file, but that's about all I can tell. As for plugins, yes I'm using some:

active_rbac ajaxscaffoldp engines calendar_helper (not really using this right now, but it's in the plugins directory) exception_notification

My webrick seems to be whacked now as well:

$ script/server webrick => Booting WEBrick... /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.1/lib/commands/servers/ webrick.rb:11: warning: already initialized constant OPTIONS => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails application starting on => Call with -d to detach => Ctrl-C to shutdown server ** Starting Mongrel listening at ** Starting Rails with development environment... Exiting /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.1/lib/commands/servers/ mongrel.rb:15: warning: already initialized constant OPTIONS /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.1/lib/commands/servers/ mongrel.rb:18: undefined method `options' for :Array (NoMethodError)         from /usr/local/lib/ruby/site_ruby/1.8/rubygems/ custom_require.rb:33:in `gem_original_require'         from /usr/local/lib/ruby/site_ruby/1.8/rubygems/ custom_require.rb:33:in `require'         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ active_support/dependencies.rb:496:in `require'         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ active_support/dependencies.rb:343:in `new_constants_in'         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ active_support/dependencies.rb:496:in `require'         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.1/lib/ commands/server.rb:39         from /usr/local/lib/ruby/site_ruby/1.8/rubygems/ custom_require.rb:33:in `gem_original_require'         from /usr/local/lib/ruby/site_ruby/1.8/rubygems/ custom_require.rb:33:in `require'         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ active_support/dependencies.rb:496:in `require'         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ active_support/dependencies.rb:343:in `new_constants_in'         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.0/lib/ active_support/dependencies.rb:496:in `require'         from script/server:3

I'm crashing and burning. It's always so hard to go back.... I'm glad I tagged the source tree!


Hi Mike, do you no if all the plugins that you're using within you're app has been upgraded for rails 1.2.x? If not, then I would highly recommend the following course of action:

a) downgrade to rails 1.1.6


b) resolve the issues in regards to the plugins

Last but not least, could you send me the output of the following:

gem list



Check this post: http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/ efeb1eacdf81a0b5/b1eab53f3986b0c5


I'm having some difficulties at working out how I'm supposed to answer appropriately to XML-requests in my new RESTful controllers. Especially the suggested behaviour on errors is of much interest to me.

For example, if an item was not found, I understand that I should send a 404 error. I'm doing this by something like: render :text => "Not found", :status 404

However, I do not really feel comfortable with that. Is this the best way to throw out HTTP status codes?

Thanks in advance!

Greetings, Christoph

I too have recently been looking into this while building a REST API. It seems there is no standard for error messages. What I’ve done is return both the HTTP status code as well as a human-readable XML document with an explanation of the error in one of the nodes. This is the helper method I’m using:

def render_xml_error(status, text = “”) if text.blank? case status when 400 text = “Resource invalid” when 404 text = “Resource not found”

    when 405
      text = "Method not allowed"
    when 406
      text = "Not acceptable"
    when 500
      text = "Application error"
    else "Error"

render :xml => "<error>#{text}</error>", :status => status



How can I downgrade?

1) Change version in environment - seems like a slam dunk 2) rake rails:update VERSION=1.1.6 (I'm just guessing here) 3) does gem keep the old version unless I clean up? I think I read that somewhere...

Oh, pooh. I hate going backwards. Anybody want to help me out?
Living life on the tips can be fun, but dangerous!


How can I downgrade?

If you used gems and haven't removed the old versions, you should be able to specify the version to use in environment.rb: RAILS_GEM_VERSION = '1.1.6'

You can also checkout version 1.1.6 into /vendor/rails/ and the application will use that instead. That would be the ideal method if it's only one app that is causing you problems.


Until the engines 1.2 release is official, use this:

  rm -fr vendor/plugins/engines   svn co http://svn.rails-engines.org/engines/branches/rb_1.2 vendor/ plugins/engine

Send any feedback to the engines mailing lists or the issue tracking site - see rails-engines.org for more information. The better the feedback, the sooner I can make 1.2 official.

Just to close this out...

I did change my environment.rb back to 1.1.6 and got it all working.
I learned a bunch in the process as well! Thanks to everybody who responded. The idea of putting rails into my vendor folder is attractive for locking down a complete configuration for production.
As of now, I'll go free with the idea that the RAILS_VERSION thing will work. When the new engines is out I'll give the 1.2.1 update another swing.

Editorial: There are really good people in this group. Thank you all.


Thanks, that makes sense to me. I'll try something similar. Quite odd though that there seem to be quite few people bothered with that problem in general.

Greetings, Christoph

Ed Hickey schrieb: