当在Rails中使用gem时,'无法删除Object :: ClassMethods'是干什么的? [英] When working with gems in Rails, what does 'cannot remove Object::ClassMethods' stem from?

查看:81
本文介绍了当在Rails中使用gem时,'无法删除Object :: ClassMethods'是干什么的?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述



有没有人知道这是源于什么?我已经看到了几种不同的情况,但仍然没有知道究竟是什么导致了它。

  $ sudo耙宝石:install --trace 
(in / u / app / releases / 20100213003957)
**调用gems:install(first_time)
**调用gems:base(first_time)
**执行宝石:base
**调用环境(first_time)
**执行环境
rake中止!
无法删除Object :: ClassMethods
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in`remove_const'
/ u / app / releases / 20100213003957 / vendor / rails / activesupport / lib / active_support / dependencies.rb:603:在`remove_constant'
/ u / app / releases / 20100213003957 / vendor / rails / activesupport / lib / active_support / dependencies .rb:603:`instance_eval'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in`remove_constant'
/ u / app /releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in`new_constants_in'
/ u / app / releases / 20100213003957 / vendor / rails / activesupport / lib / active_support / dependencies。 rb:549:在`each'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in`new_constants_in'
/ u / app /释放/ 20100213003957 /供应商/轨道/的ActiveSupport / LIB / active_support / dependencies.rb:1 56:在`require'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/misc.rake:4
/usr/lib64/ruby/gems/1.8/gems /rake-0.8.4/lib/rake.rb:617:in`call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617: in`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in`each'
/ usr / lib64 / ruby​​ / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:612:在`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake .rb:578:在`invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in`synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake -0.8.4 / lib / rake.rb:571:在`invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in`调用'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/gems.rake:17
/usr/lib64/ruby/gems/1.8/gems/rake-0.8 .4 / lib / rake.rb:617:在`call'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib /rake.rb:612:in`each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in`invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242: in`synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in`invoke_with_call_chain'
/ usr / lib64 / ruby​​ / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:588:在`invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake .rb:585:在'each'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in`invoke_prerequisites'
/ usr /lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in`invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in`同步'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in`invoke_with_call_chain'
/ usr / lib64 / ruby​​ / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:564:在`invoke'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb :2027:在`invoke_task'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in`top_level'
/usr/lib64/ruby/gems/1.8/ gems / rake-0.8.4 / lib / rake.rb:2005:在`each'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005 :在`top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in`standard_exception_handling'
/ usr / lib64 / ruby /gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in`top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/ rake.rb:1977:在`run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in`standard_exception_handling'
/ usr / lib64 / ruby​​ / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:1974:在`run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8 .4 / bin / rake:31
/ usr / bin / rake:19:在`load'
/ usr / bin / rake:19
pre>

解决方案

导致此错误的原因是双重例外。通常,代码中的某些内容会崩溃,这会引发初始异常。然后Rails的定制需要通过移除部分定义的常量来保持名称空间的清洁,这是 new_constants_in 方法的用途。问题在于 new_constants_in 没有正确地处理代码中的某个特定构造,我怀疑是由于模块名称空间的错误处理或某事(因为ClassMethods可能位于某个模块之外目的)。在任何情况下,我都没有将错误追溯到Rails组件或其他任何东西,因为坦白地说,这不值得付出努力。



解决方案对Rails核心的侵入性稍微小一点)是一个快速的黑客来找出什么提出了最初的例外。所有你需要做的就是去调用 Dependencies.new_constants_in 并注释掉(这里有几个地方可以)。例如:

  def require(file,* extras)#:nodoc:
如果Dependencies.load?
Dependencies.new_constants_in(Object){super}
else
super
end
rescue Exception =>来自所需文件的异常#错误
exception.blame_file! file
raise
end

注释 new_constants_in stuff:

  def require(file,* extras)#:nodoc:
#如果Dependencies.load?
#Dependencies.new_constants_in(Object){super}
#else
super
#end
#rescue Exception =>来自所需文件的异常#错误
#exception.blame_file! file
#raise
end

然后你会马上看到你的错误。


Frequently I have run into a problem when installing gems that provides a problem like:

Does anyone know what this stems from? I've seen in it several different cases, yet still haven't learned what exactly is causing it.

$ sudo rake gems:install --trace
(in /u/app/releases/20100213003957)
** Invoke gems:install (first_time)
** Invoke gems:base (first_time)
** Execute gems:base
** Invoke environment (first_time)
** Execute environment
rake aborted!
cannot remove Object::ClassMethods
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_const'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `instance_eval'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `each'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/misc.rake:4
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/gems.rake:17
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in `invoke_task'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1974:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19

解决方案

The cause of this error is a double exception. Usually something in your code is crashing, which raises an initial exception. Then Rails' custom require attempts to keep the namespace clean by removing partially defined constants, which is the purpose of the new_constants_in method. The problem is that new_constants_in is not properly handling some particular construction somewhere within the code, I suspect due to mishandling of module namespaces or something (because ClassMethods is probably inside some module other than Object). In any case, I have not traced the error back to a Rails component or anything else, because frankly it's not worth the effort.

The solution (short of proposing something a little less invasive to Rails core) is a quick hack to figure out what raised the original exception. All you need to do is go to where Dependencies.new_constants_in is called and comment it out (there are a few places where this could be). So for example:

def require(file, *extras) #:nodoc:
  if Dependencies.load?
    Dependencies.new_constants_in(Object) { super }
  else
    super
  end
rescue Exception => exception  # errors from required file
  exception.blame_file! file
  raise
end

Comment out the new_constants_in stuff:

def require(file, *extras) #:nodoc:
#  if Dependencies.load?
#    Dependencies.new_constants_in(Object) { super }
#  else
    super
#  end
#rescue Exception => exception  # errors from required file
#  exception.blame_file! file
#  raise
end

Then you'll see your error straight away.

这篇关于当在Rails中使用gem时,'无法删除Object :: ClassMethods'是干什么的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆