I am attempting to remove caching and discovered this post:
How to prevent browser page caching in Rails
The problem it along with a number of other posts relating to ruby rails refer to an application_controller.rb file that my project does not have. I inherited this system so wasnt part of its initial development. Can someone explain why this would be the case? I am using padrino and in my config folder i have the following files:
Deploy
production.rb
staging.rb
Recipes
base.rb
nginx.rb
rbenv.rb
apps.rb
boot.rb
From what you've provided me I can say that I'm quite certain the project is using the Padrino ruby framework and not rails :)
See: http://www.padrinorb.com/
Related
I have a class in the lib directory: lib\db_cache.rb, that defines class DbCache.
My Rails model can access it when in dev mode and also when I run rails console in production mode.
But when I run the production mode rails server, the model class, eg Foo, complains about "uninitialized constant" Foo::DbCache,
org/jruby/RubyModule.java:2677:in `const_missing',
org/jruby/RubyMethod.java:134:in `call'
I have this line in application.rb
config.autoload_paths += %W(#{Rails.root}/lib)
I have also tried the other variations shown in the linked SO questions - but no joy.
I am using jruby 1.7.3 (1.9.3p385) - Java 1.7.0_13-b20, on linux. Rails is version 3.2.12.
I've seen these questions Rails - why would a model inside RAILS_ROOT/lib not be available in production mode? and Best way to load module/class from lib folder in Rails 3? but that doesnt seem to help my case.
Thanks in advance for any ideas on this.
PS My work-hack-around for now is to require 'db_cache' in my model class :(
It sounds like you are trying to extend a class. Without seeing the db_cache.rb file I can't know for sure.
If that is the case it is perfectly fine to have
extend DbCache
in your model class definition
The problem seemed to related to enabling config.threadsafe! in /config/environments/production.rb
This is what I had:
# Enable threaded mode
if defined?(Rails::Server)
puts "Rails Server running - so enable threadsafe!"
config.threadsafe!
end
As I am using jruby, I dont believe this is so much of an issue. At least, when I removed these lines, things worked much better :)
Is there anything in the Sinatra / Rack world similar to Rails configuration loading scheme that loads one of the config\enviroments\*.rb files depending on Rails.env
I know I could develop one pretty easily, i was just wondering if there was something already in place.
If you're following the Rails convention of putting a file for each environment in config/environments/environment_name.rb, you can put something like this in your Sinatra app, or for Rack in your config.ru file:
Dir.glob(File.dirname(__FILE__) + "/config/environments/#{settings.environment}.rb", &method(:require))
With some minor modifications you could make it load other file locations/combinations. Sinatra's configure blocks work just as well, too.
It turns out that there is something from Sinatra, that provides a similar, though limited, functionality.
See the code:
https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1120
So that you can do this:
class MyApp < Sinatra::Base
configure :development, :test do
#only executes this code when environment is equal to one of the passed arguments
# I'm pretty sure Sinatra sets this based on ENV['RACK_ENV']
end
end
There is one called Sinatra::ConfigFile, which now lives in Sinatra::Contrib http://www.sinatrarb.com/contrib/config_file.html
There's lots of useful stuff in there.
I adapted mine from monkrb.com (it's also yaml in RoR anyways)
YAML.load_file(path_of "config/settings.yml")[RACK_ENV]
e.g.
http://github.com/codepants/yasumi/blob/master/config/settings.yml
I have installed a plugin to my Rails app. The plugin has files in its public directory that I want to make available.
For example, vendor/plugins/myplugin/public/javascripts/myplugin.js. Can I make this available via Rails at /javascripts/myplugin.js?
I've got it working by copying the files from vendor/plugins/______/public/* to public/*, but that seems like a bad idea.
I think this only works if you make your plugin into an engine. Engines can access deeper into the rails initialization process so they can add an additional static asset path.
Here is a snippet of my engine.rb file that does this:
module MoxieForum
class Engine < Rails::Engine
initializer "static assets" do |app|
app.middleware.use ::ActionDispatch::Static, "#{root}/public"
end
end
end
I recently wrote a handy starting point for creating a rails 3 engine that has this and lots of other basic functionality built in:
http://keithschacht.com/creating-a-rails-3-engine-plugin-gem
with rails 2.1 at least copying used to be "the only way" (I think it probably still is, though you could use mod_rewrite apache module to get them all...)
Whenever two concurrent HTTP requests go to my Rails app, the second always returns the following error:
A copy of ApplicationController has been removed from the module tree but is still active!
From there it gives an unhelpful stack trace to the effect of "we went through the standard server stuff, ran your first before_filter on ApplicationController (and I checked; it's just whichever filter runs first)", then offers the following:
/home/matchu/rails/torch/vendor/rails/activesupport/lib/active_support/dependencies.rb:414:in
`load_missing_constant'
/home/matchu/rails/torch/vendor/rails/activesupport/lib/active_support/dependencies.rb:96:in
`const_missing'
which I'm assuming is a generic response and doesn't really say much.
Google seems to tell me that people developing Rails Engines will encounter this, but I don't do that. All I've done is upgrade my Rails app from 2.2 (2.1?) to 2.3.
What are some possible causes for this error, and how can I go about tracking down what's really going on? I know this question is vague, so would any other information be helpful?
More importantly: I tried doing a test run in a "production" environment just now, and the error doesn't seem to persist. Does this only affect development, then, and need I not worry too much?
This is a bug in Rails 2.3.3:
https://rails.lighthouseapp.com/projects/8994/tickets/2948-exception-a-copy-of-actorscontroller-has-been-removed-from-the-module-tree-but-is-still-active
There is a patch for it (but incomplete?) in 2-3-stable:
http://github.com/rails/rails/commit/d37ac7958fc88fdbf37a8948102f6b4e45c530b3
You have a few options to address the problem:
Revert to Rails 2.3.2, wait for 2.3.4 to come out, probably at the end of August. 2.3.3 has a couple bad issues, so that might be best.
The problem should not happen in production mode, nor will it happen in development mode under the Thin server. If you are having this issue on Google Engines in production mode, the patch is your only hope. If it's only in dev mode, you can just run your local server with Thin instead of Mongrel.
If it is Google Engines, you can move off of Google Engines and host your app another way. This seems like a lot of work though.
Best of luck, this is a really bad bug many people are running into.
I addition to the workarounds mentioned in the other answers, I have encountered two others:
Add "config.cache_classes = false" to your config/environments/development.rb file. This has the unfortunate side effect of requiring you to restart your server whenever you want to see your changes.
Add 'unloadable' inside your controller classes in your engine. See http://strd6.com/?p=250 and http://dev.rubyonrails.org/ticket/6001
I haven't tried the second approach, since I found the other solution first, but there is of course a trade-off between avoiding having to edit plugin code, which may be reverted if a newer version of the plugin is downloaded, and then the ease of development provided by not having to restart the development server all the time in the second solution.
i faced with same problem for my new engine on rails 2.3.4 and i found solution here.
calling unloadable method solved my problem.
Weird.
Trying running "rake rails:update" to make sure the configs are scripts are up to date. You may have to check the existing ones against a template application.
i had this error and from memory it was one of one of these three things that fixed it.
1) I needed to update mongrel/rack
2) I had an environment variable from restful authentication that i had moved into the production.rb and development.rb files from the environment.rb - shifting it back to environment.rb seemed to help
3) will_paginate was out of date
We called out to an activerecord model in a namespaced module which overrides the "name" class method. Rails expects that the name method returns Product::Categories::MilkProducts::Firstproduct but gets just Firstproduct and throws an error. So if you get this error first check if you redefined self.name.
Firstproduct.method(:name).owner should be Module
Firstproduct.method(:name).source_location
source:
module Product::Categories::MilkProducts
class Base
def self.name
self.to_s.demodulize
end
end
class Firstproduct < Base
self.product = Product.first
end
end
I am trying to create Sinatra based heroku app without any luck?
To answer your question: Yes!
For reference: http://docs.heroku.com/rack#sinatra
The sinatra application should be as you always do but on the root of your application you should include a config file named config.ru
It basically says:
require 'application' run
Sinatra::Application
There is a new, slightly different procedure for deploying Sinatra (and other Ruby) apps on Heroku/Cedar which involves "foreman" (and a Procfile)... see getting started guide for Ruby:
http://devcenter.heroku.com/articles/ruby