| Issue 29: | Passenger incompatible with edge Rails (April 19 2008) | |
| 6 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Stack trace is shown here: http://groups.google.com/group/phusion-passenger/browse_thread/thread/3182678b1862c3f1?hl=en The problem is that AssetTagHelper runs something like this: ASSET_DIR = Rails.public_directory public_directory, in turn, relies on RAILS_ROOT, which isn't available during preloading of the Rails framework. A patch should be sent to Rails. The patch should remove the assumption that RAILS_ROOT is available, and should add a method for allowing re-initialization of constants such as ASSET_DIR, after RAILS_ROOT has been set. |
||||||||||||||
,
Apr 19, 2008
Is there a temporary workaround until it's fixed in Rails? |
|||||||||||||||
,
Apr 19, 2008
There's no workaround at the moment. |
|||||||||||||||
,
Apr 20, 2008
(No comment was entered for this change.)
Labels: -Priority-Medium Priority-High
|
|||||||||||||||
,
Apr 21, 2008
I'm not sure I agree. The boot.rb file defines RAILS_ROOT at the very top, one of the first things Rails.boot does is to call the preinitialize method. That method itself even uses RAILS_ROOT, even VendorBoot.run uses it as a value in the require. So by the time Rails::Initializer.run is called RAILS_ROOT is very well defined and should not error out. This seems to only be a problem with Passenger. I really think this is something in the way framework_spawner.rb is working. In fact, if look at the code, you are only accounting for RAILS_ROOT in the application spawner. I would imagine that the rails framework is going to rely more and more on RAILS_ROOT being defined, so I think if Passenger is going to sidestep the boot.rb process which does that well ahead of time, then you need to do so in both your application and your framework spawner. Does that sound reasonable? |
|||||||||||||||
,
Apr 21, 2008
For instance, this hack works for me. http://github.com/metaskills/passenger/commit/69afcd75425a89c9d17d1fc40c0a7571d6bd547c Sorry, I'm not on the rspec bandwagon, or I would have written some tests. |
|||||||||||||||
,
Apr 22, 2008
Hi metaskills. The reason why FrameworkSpawner exists, is to reduce memory usage and startup time. The idea is that the FrameworkSpawner loads all Rails framework code. Then, whenever an application needs to be spawned, the FrameworkSpawner creates a child process, which already contains the Rails framework. This removes the need to load the Rails framework over and over, which reduces startup time. And because the child process shares most memory with its parent process, memory usage is reduced. However, *any* application, i.e. with any application root, may be spawned using a FrameworkSpawner. Your change works in the case when Apache only serves a single application, but will fail if it serves multiple applications (assuming that they aren't all vendoring Rails, in which case your solution would work). I think the reduced startup time and reduced memory usage is a pretty good reason to make Rails rely less on RAILS_ROOT being available during boot. So I think it would be better to patch Rails instead. |
|||||||||||||||
,
May 01, 2008
Fixed in the development version (git repository).
Status: Fixed
Labels: Milestone-1.1.0 |
|||||||||||||||
 Sign in to add a comment
|
|||||||||||||||
