[PATCH][TINY] Expected x.rb to define X error

You're certainly not alone, frido! See, for example:

• http://blog.teksol.info/articles/2007/03/09/expected-x-to-define-y-error
• http://www.ruby-forum.com/topic/77708
• http://railsforum.com/viewtopic.php?id=2716

Oh, here's some more: http://weblog.rubyonrails.org/2006/8/11/reloading-revamped

Expected app/models/market/market.rb to define Market

Expected vendor/plugins/unobtrusive_javascript/lib/unobtrusive_javascript.rb to define UnobtrusiveJavascript

I've gotten it too...

The first time it was for a simple model, and yes, we double-checked that the file in question did indeed define a Whatever < ActiveRecord::Base . (I'm not sure how we fixed it but somehow we got it to go away eventually...)

Most recently I'm getting the error for something in a plugin...

active_support/dependencies.rb:249:in `load_missing_constant': Expected vendor/plugins/database_log4r/lib/log4r/deferrable_database_outputter.rb to define Log4r::DeferrableDatabaseOutputter (LoadError)

vendor/plugins/database_log4r/lib/log4r/deferrable_database_outputter.rb:

module DatabaseLog4r
  class DeferrableDatabaseOutputter < Log4r::Outputter

Anyone know what's going on??

Okay, I found what was wrong in my particular case. And yes, I admit, I was wrong, the error message was correct -- I just didn't read it carefully enough.

The problem was simply that I was referring to Log4r::DeferrableDatabaseOutputter when I should have been referring to DatabaseLog4r::DeferrableDatabaseOutputter...

And since this plugin didn't follow Rails' convention of module_name/class_name, I can see why load_missing_constant tried to load that file...

Even if I do an explicit require 'log4r/deferrable_database_outputter.rb', it still gives this error.

Oh well, I guess in this particular case, the error sort of almost makes sense... We'll see if that is still the case next time I run into this error ...

I came upon this suddenly in my own code, in a class that was previously working just fine. I'm not sure what triggered it, as I've been doing at lot of changes lately.

It ONLY came in in production mode - same exact code, similar data, and in dev mode it'd work fine. And it ONLY affected one controller - the one I'd been working with.

I suspect this setting in /config/environments/production.rb: config.action_controller.consider_all_requests_local = false

I changed this to 'true', restarted the server, and it worked. I then set it BACK to 'false', restarted... and it still worked.

So, I don't really know for sure WHY it started working again or how this might be causing it, but hopefully it helps.

This error is the only issue keeping me frozen at 1.1.6. Here, it happens with activesupport-1.4.2. Trace to doc the line number in dependencies.rb:

Expected ./script/../config/../app/controllers/welcome_controller.rb to define WelcomeController C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:249:in `load_missing_constant'

It's strange, that unported, fresh rails projects created from scratch do not produce this error. I tried to copy config files from one projects to the other with no effect.

Sorry, this should stay on edge, of course.

Replying to frido:

Hi,

The problem arises when a model, controller, plugin etc. is named using '_', for example model named 'my_model' will have this error, whereas model 'mymodel' will work fine. The solution is simple: as every model or controller no matter what in the model or controller file by default is named without '_' My_model => MyModel, all that's have to be done is to add another definition of the class:

(by default the My_model model file looks like this) class MyModel < ActiveRecord::Base end

(make it look like this) class MyModel < ActiveRecord::Base end

class My_model < ActiveRecord::Base end

Rihards

No I'm sorry, the name is ShopController not Shop_Controller, but the file is named shop_controller. As you can see on my first posting: class ShopController < ApplicationController

And BTW it's not me how has named that file it's rails.

Regards Friedrich

Replying to frido:

No I'm sorry, the name is ShopController not Shop_Controller, but the file is named shop_controller. As you can see on my first posting: class ShopController < ApplicationController And BTW it's not me how has named that file it's rails. Regards Friedrich

I assume that it is a bit different with controllers. The method sure worked with models. Anyway I would suggest trying to add another class in the shop_controler.rb, perhaps Shop_Controller < ApplicationController might work.

Replying to frido:

I ran into this problem tonight. I can't say for sure what your issue is but for me, the problem stemmed from a collision from Subversion regarding the controller my system is complaining about.

I did an SVN UP to bring in the latest code from the repository. I usually don't pay attention to it but this one time, I noticed the conflict. My controller code had the subversion markup in it and there were the extra versions (.r32, .mine) of the controller file.

I deleted all of the controller files for the controller and restored from the repository. All is well now.

Good luck.

MCN

I've been getting the Expected x.rb to define X error in the Exception_Notification plugin under Rails 1.2.3.

I got the error consistently via rake db:migrate for the PIP application.

The error happened consistently and had nothing to do with which server I was(n't) running.

Expected /.../pip/config/../vendor/plugins/exception_notification/lib/exception_notifier.rb to define ExceptionNotifier

The answer to my problem was in a link supplied above (thanks TylerRick): http://weblog.rubyonrails.org/2006/8/11/reloading-revamped

The critical comment at that link is: "Prior to this revision, Rails would happily load files from Ruby’s standard lib via const_missing; you will now need to explicitly require such files."

The trace showed the error was coming from const_missing.

It took a while for all this to sink in, but when it finally did, all I had to do was put a require statement in the right place - the plugin's init.rb.

The error message puzzled me for quite a while, plus the fact that I hadn't changed the plugin before it broke.

I think require statements will solve Friedrich's problem. Let us know Friedrich.

Some of the other issues raised above seem to be slightly different to Friedrich's problem. Thanks for registering the problem Friedrich - it was a big help to me.

May all be but where should the require be placed? It's not a plugin nor anything special it's Rails generated class, and nothing more.

Friedrich

I reread all you messages, but they do not fit into my problem description. It is not a Model clas it's ruby generated Controller class. It starts simple enough with: class ShopController < ApplicationController

Now if I start with a new rails application: I generate the controlelr simply by typeing

./script/generate controller Test

and I got class TestController < ApplicationController end

in a file named test_controller.rb

I add a simple index.rhtml and am done with it. So where is the difference to the header before. I can not see it and I have not the slightest clue what's broken.

Regards Friedrich

Hi Friedrich

From memory, I found 4 instances of this error arising in different circumstances - in each case I had to put a require statement in an appropriate place.

I can't say for sure what the solution to your problem is or how similar your problem is to the ones I had. In my case, in all occurrences, there was nothing wrong with the class itself. But the class was being referenced in a place Rails didn't expect it to be referenced. In a couple of instances a model class was being referenced indirectly in a migration file - so, once I "required" the model class for the migration, the problem disappeared.

Trying to see how that might help you, I believe you that there is nothing wrong with your Rails-generated controller - but, somehow, somewhere else in the course of your application booting and running, either that controller is not being "required" in the normal course of startup or, something is referring to that controller in a place or in a way Rails hasn't expected. I'm only speculating and I don't want my speculation to mislead you or waste your time. But I'm suggesting you have to look away from your Rails-generated controller to see the cause of the problem. And that's about as specific as I can be from here.

If this problem is a stopper for you and you'd like me to take a look at your code - no promises, of course - I'm happy to take a look.

regards

Greg

where did you look into for this problem? I can not make anthing from the backtrack:

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `each'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243

/usr/bin/mongrel_rails:16:in `load'

/usr/bin/mongrel_rails:16 Expected /var/www/rails/shop/config/../app/controllers/shop_controller.rb to define ShopController

/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:249:in `load_missing_constant'

/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:452:in `const_missing'

/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:464:in `const_missing'

/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/inflector.rb:250:in `constantize'

/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/core_ext/string/inflections.rb:148:in `constantize'

/usr/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/routing.rb:1284:in `recognize'

/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:40:in `dispatch'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:78:in `process'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in `synchronize'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in `process'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in `process_client'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `each'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `process_client'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `initialize'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `new'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `initialize'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `new'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `each'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run'

/usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243

/usr/bin/mongrel_rails:16:in `load'

/usr/bin/mongrel_rails:16

Looks to me like a request route is being processed here:

/usr/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/routing.rb:1284:in `recognize'

and the problem arises out of the attempt process the route.

Does every URL generate this error, or only some URLs?

Ok, it seems it fails on any URL. I introduced a new function in this Controller which should be found at test but that fails, also, so I will first look into this. However it does not explain why this works fine in Rails 1.1.6 and fails in higher versions.

Howerver thanks for the hing, at least something I can look after.

Regards Friedrich

Just an afterthought. Could it be that the error is related to using the login_engine?

Regards Friedrich

Good luck with it Friedrich. Let us know how you go.

If your app isn't too complex or large, another technique would be to progressively copy sections of it into a freshly generated Rails application and see at what point the fresh Rails app fails with the same error. This can give you a clue as to where the problem lies, but it doesn't necessarily suit all problems and is a diagnostic last resort.

Perhaps a better approach in your case would be to start pulling pieces off (a copy of) your application until all that you are left with is the shop controller - which should work if everything else has gone. So, at some point in the dismantling process, your dismantled app will presumably go from "not working" to "working" - and then you can examine what was the latest thing removed to find out what was going on.

As for what has changed since 1.1.6 - I think dependencies.rb has changed since then. See this note about Edge Rails in Aug 2006:

"The actual mechanics of Dependencies are now relatively simple. Instead of using Reloadable to decide which classes to unload, Rails records which constants are loaded via const_missing. When the request is completed, each autoloaded constant is removed, leaving the process in a clean state. The actual mechanics are slightly more complex, but not inordinately so. Feel free to open dependencies.rb and peruse the code." - [http://weblog.rubyonrails.org/2006/8/11/reloading-revamped ]

The problem trace you sent shows dependencies.rb striking a problem in const_missing.

I'll take Nicholas' advice and take a look at dependencies.rb when I get a chance.

---

Just saw your comment re the login engine. I don't know - maybe. But if you use the dismantling technique, then the idea is that you take the easy-to-remove or highly suspect components away first, so perhaps the login engine could go. But if the login engine is widely used, I'd expect you'd have heard others having the same problem. From my distance the login engine seems an unlikely cause - unless you've modified it to know about the internals of your application. (I'm not familiar with the login engine itself, so you'd know much more about it than me.)

One other thing with the dismantling approach - if you can easily remove a whole slab of your application e.g. 50%, then do it for that diagnostic. The idea is to most efficiently narrow down the area in which your problem is hiding.

Well I'm following the start from the beginning route, first without the login engine and then I'll see what'll happen. Howerver this is a "nasty" thing....

Regards Friedrich

We're running a cluster of six mongrels behind Apache2.2 on Ubuntu Linux 7.04. We ran into this exact problem after upgrading to Rails 1.2.3 from 1.1.6, where sometimes an individual mongrel will fail with this bug's error message.

The strange thing is that only a few out of the six will fail. We've found that after restarting the individual mongrels that failed (one at a time using mongrel_rails start ...etc...), the problem doesn't show up any more. However, if we start up the cluster all at the same time using mongrel_rails cluster::start ...etc..., then at least one of the mongrels gives us this error on certain pages.

Also, starting with no mongrels running, then firing up each one individually, giving each one time to completely load, no mongrels seem to fail. This really isn't very scientific, but could there be a slight incompatibility the new rails 1.2.3 loading process and mongrel_cluster?

By the way, it only happens in production mode. In development mode everything's fine.

I had similar problems today as I tried to upgrade from 1.1.6 to 1.2.3. They vanished when I deleted plugin engines.

I have the completely same problem here. But to have it even better, it happens only on Linux production machine. On my Windows development machine, I can run app in production mode. So maybe some upper/lower case file naming bug? Windows does not care about this, Unix does.

Ok, I have just solved my problem - ruby-gettext 1.8 is not compatible with Rails 1.2. Actually, error message is completely pointless, thus causing nice headache and should be improved.

Nothing that we have tried above has helped. We're not using the ruby-gettext gem, however there are some differences in the gettext libraries that may the culprit. A possible workaround is here: http://beast.caboo.se/forums/2/topics/1064. I will report back if we find the gettext libs are the problem.

Replying to cblackburn:

Nothing that we have tried above has helped. We're not using the ruby-gettext gem, however there are some differences in the gettext libraries that may the culprit. A possible workaround is here: http://beast.caboo.se/forums/2/topics/1064. I will report back if we find the gettext libs are the problem.

Sorry, wrong URL for that possible workaround: http://rubyforge.org/tracker/index.php?func=detail&aid=5521&group_id=1044&atid=4083

Update: I have determined that the problem, for me, only occurs in production mode and it seems to have a problem with the loader when using Controllers in a different namespace. For example Admin::DashboardController. Any controllers outside the default namespace seem to have this problem, but only in production mode. Not sure if this helps because frido's original report uses the default namespace.

So whenever a request uses Admin::DashboardController I get:

A LoadError occurred in dashboard#index:

  Expected current/config/../app/models/game.rb to define Game
  /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:249:in `load_missing_constant'

As far as I can tell, it doesn't have anything to do with the gettext libraries.

BTW: I am running on rails 1.2.3, FreeBSD 6.2-STABLE

Finally, I found that acts_as_ferret was borking the loader somehow. I removed all acts_as_ferret references and everything is fine again. Hopefully this will help someone.

I don't think that I've seen anyone report an error with the FormBuilder. Also, this problem is present 1.2.1 as well.

Expected script/../config/../app/helpers/multiple_submit_builder.rb to define MultipleSubmitBuilder

When using something like

<% fields_for :character, volunteer.character, :builder => MulitpleSubmitBuilder %>

When I use this with a standard

<% form_for :url => { :action => 'new' }, :builder => MultipleSubmitBuilder %>

It almost appears as if it isn't loaded at all; the MultipleSubmitBuilder is described as being a nonexistant constant.

I am having this error in development mode. I have tried restarting the server, setting the file as executable, and using WEBrick. I'm quite frustrated with this error as it's putting a stop on my development.

Oh, it seems this bugs is not that easy to fix because one can not even spot it ;-( Just so much after restarting and dropoing the Login Engine stuff the error does not show here. So currently it seems this error is related to "engines". But well let's see what'll happen with it ;-)

Regards Friedrich

Replying to JonTec:

Spelling error. Let me forever live in shame. Disregard my information about FormBuilders.

FYI: I just tested and found the same issue in rails 1.2.0

Though I'm still not sure what the cause is, I've been able to fix this on the production server by going to the console (./script/console production) and just typing the name of the class which Rails is having trouble loading. So mysterious!

I just experienced the same problem. I was running an app on a Ubuntu 6.10 box w/ rails 1.1.6. We built a newer faster Ubtuntu 7.04 box w/ rails 1.2.3. One of our two production started to exhibit this problem in one of the models. The rest of them worked just fine.

I forced the app back to development mode, and it works like a champ.

My model is pretty darn basic

class Log < ActiveRecord::Base
  validates_presence_of :Temperature
  ...
end

We have about 5 or 10 validates_presence of, and I really did not want to retype them all from memory. :)

Hi all,

I had this weird error, when I launched:

./script/console production

I got a more precise error that helps me solve the problem directly. If it can help...

Maxime

I got this error as well.

It seems I got it when trying to use methods (e.g. "acts_as_foo") in my models, when those methods were added to the class by requiring files from the "lib" directory in "environment.rb".

As a workaround, things would start working if I required these files from the model file: so e.g. 'require "acts_as_foo"; class User < ActiveRecord::Base'.

A simpler solution that worked for me, though, is to simply change "config/environments/test.rb" from

config.cache_classes = true

to

config.cache_classes = false

Had to make the same change in "config/environments/production.rb" to make that environment work as well.

Obviously, turning off caching likely decreases performance some.

So it seems one solution is to turn of class caching in test and production; another is to require files that extend models in the model files themselves, not in "environment.rb".

I resolved my instance of the problem by moving a require from the top of a file to the inside of the ActiveRecord model definition.

E.g. I had:

require 'digest/sha2' class User < ActiveRecord::Base

And I changed it to:

class User < ActiveRecord::Base require 'digest/sha2'

I really didn't expect it to work, but that seems to be true of most of the fixes on this bug.

Ack. Here's what I tried to say in the previous comment.

Going from:

require 'digest/sha2
class User < ActiveRecord::Base

to:

class User < ActiveRecord::Base
require 'digest/sha2

Most of the time that I've been able to fix this, it's been by re-installing gems and fixing other load path issues. I added a TINY patch, see the diff file, which elaborates *very* slightly in the error message.

I was having this problem using restful_authentication with activation (and thus ActionMailer) in rails v 1.2.3. Initially I was getting the "no rhtml rxml rjs or delegate template found" error and followed the instructions on this blog: http://blog.zmok.net/articles/2006/09/18/work-your-way-around-no-template-found

After that, I started getting the "Expected x.rb to define X" error.

Turns out that ActiveMailer (with Localization installed?) was looking for an rhtml file called signup_notification_en.rhtml, but installing restful_authentication created signup_notification.rhtml (without the language extension). Renaming the file to include the language extension worked, but this doesn't seem like the best solution.

For me, going to c:\ruby\lib\ruby\gems\1.8\gems\activesupport-XXX\lib\active_support\dependencies.rb and changing lines 341:

begin

yield # Now yield to the code that is to define new constants. aborting = false

to this

begin

yield # Now yield to the code that is to define new constants. aborting = false

rescue Exception => detail print "heres your e" + detail.to_s, "\n"

helped me discover the real problem--a function name which was wrong within a class. Guess that'll do until I can figure out how to submit a real patch. GL! -Roger

Just remember to change it back when you're done--in reality the code above doesn't raise the exception it catches (it should). So better code replacement would be

begin

begin

yield # Now yield to the code that is to define new constants. aborting = false

rescue Exception => detail

print "\n\n\nheres your e:" + detail.to_s, "\n" +detail.backtrace.join("\n") raise

end

Other than that note that my grief was caused by a plugin named "a-b-c" -- rename it a_b_c and I was good in test and development modes.

Another cause of this is if you have multiple thread that each attempt to 'load' a model or what not (i.e 5.times do Thread.new { UnknownClass } ) which fails as rails isn't thread safe. To find it I added "

print "loading #{file_path}" to line 248 of dependencies.rb (see the topmost patch).

Updating with the patch and tiny headers. It's an easy way to make life less stressful for newbies when they run into this.

Also updating the severity. This isn't critical.

I have uploaded a patch to dependencies.rb that makes error logging more explicit. Very useful. Also I noticed that within active_support/dependencies.rb there are a few options to make it more verbose that could be very helpful--edit them at the top of said file, and potentially change the "def log" function to output to the console as well as logger.

To use the patch without using edge rails you may need to download and require (another file it depends on) -- I put a copy at http://suapache.googlecode.com/svn/trunk/useful_outside_files/introspection.rb . To test the patch, add a fake function in a controller, run code that uses that controller, and see if an intelligible error message ends up in your log file. Then make sure it doesn't otherwise break your web site after you take out the bad function. If any of you do use the patch and it works, please write a reply here that says "+1" as after 3 of such messages rails will look at the patch. Thanks! -Roger

PS The patch also fixes a small bug in said file.

Replying to rogerdpack:

Please use the unified patch format. "diff -U" or, do an svn checkout, make the change and then "svn diff".

To use the latest version of the larger patch you need to apply it, then change the line of "always_output_errors" to be true. Should be good.

The patch seems to be reversed (it should be "diff -U dependencies_edge.rb dependencies.rb"). Also, the change around line 341, why create an inner begin/rescue block when there is already an outer block without a rescue?

fix of previous patch: take out redundant inner rescue block, slightly nicer output, should keep the original verbosity of it intact.

Thanks for pointing out the redundancy. -Roger

All righty in order to try my patch without going to edge rails, now download this file http://suapache.googlecode.com/svn/trunk/useful_outside_files/dependencies_more_verbose.rb and plug it in as a replacement for active_support.../dependencies.rb . Remember to give it a +1 if it works! Thanks. -Roger

Review of diff:

line 65: Replace + detail.to_s with #{detail}. also 103, 350

line 254: "check load path..." - a more detailed instruction of what to check might be helpful; and placing it in a string constant would be nice to keep this line a reasonable size.

line 447: "is_error" seems like a better name for that parameter than "high priority".

There seems to be some oddity inside I noticed--when you load it the first time and it errs, sometimes it never loads again (have to restart the server).

Anyway one other option is to hack into the logger, and set it to 'always display all messages'--some useful messages are sometimes generated during a "quiet" block, when the logger is set to be very terse, so you never see them. Would've helped me a time err two :) Will work on the patch anon. -Roger

I ran in to this problem myself in production mode after upgrading to the edge rails 2.0 preview. One of the files I was requiring in a model was using the line:

gem 'activerecord'

Changing it to...

require 'active_record'

...solved the problem.

v2, with applied suggestions: this patch takes out redundant inner rescue block, slightly nicer output, should keep the original verbosity of it intact.

it turns out that the real problem is that sometimes when rails is loading it 'swallows' error messages (!) so the idea is to hack around that somehow an easy 'attempted' fix is to go to dependencies.rb and there's some settings at the top of it to make it more verbose. Then try other things (patches, make it output all caught errors, make the logger always log everything, etc.)

You may need to also restart the server after attempting to fix a problem related to this--especially if you're running in production mode.

Here's a possible thought. I just changed my Contact.rb to Contacter.rb and also changed to class Contacter < ActionMailer::Base. I was thinking there could be two possible explainations:

1. Perhaps Rails was for some reason looking too close at ContactController, conflicting with Contact.rb. 2. Maybe a plugin already uses Contact.rb or class Contact.

To clarify, I was basically getting the same type of error, but with a Model instead.

I was experiencing this issue in production, with mongrel_rails cluster::start. It was working fine with mongrel_rails start -e production. The problem was file permissions, but I am not sure where exactly. I tried changing the mongrel config user to root and everything worked fine. Of course, this solution is bad...