Alias_method_chain causing infinite recursion and stack level too deep


#1

I installed the Facebooker plugin and upon placing it on a staging
server, I keep running into stack level too deep errors. It seems to
stem from Facebooker using alias_method_chain to override some of the
ActionController methods. I believe it’s getting loaded twice causing
confusion. I’ve tried various methods include wrapping a unless
respond_to?(:method) around the alias_method_chain call to keep it
from being called twice. However, none of this has worked? Has
anyone run into this problem and found a remedy? I know
alias_method_chain is a pretty popular way to override methods, so I
can’t imagine this being the first instance of alias_method_chain
causing this problem. Here is some of the sample code I’m looking to
fix:

module ::ActionController
class Base
def self.inherited_with_facebooker(subclass)
inherited_without_facebooker(subclass)
if subclass.to_s == “ApplicationController”
subclass.send(:include,Facebooker::Rails::Controller)
subclass.helper Facebooker::Rails::Helpers
end
end
class << self
unless ActionController::Base.respond_to?
(:inherited_with_facebooker)
alias_method_chain :inherited, :facebooker
end

end

end
end

Here you can see the method inherited has been aliased to
inherited_with_facebooker and inherited_without_facebooker has been
aliased to inherited. However, when the method is called
inherited_without_facebooker goes into an endless recursive call which
results in a stack level too deep error. I tried to prevent
alias_method_chain from being called twice (which is what I suspect
the problem being) by checking if inherited_with_facebooker already
exists. It has not seemed to fix the problem. Does anyone else have
a possible solution I may try. Thanks again!


#2

On 20 Jan 2009, at 20:48, David Law wrote:

a possible solution I may try. Thanks again!

You’re in the right mindset but you haven’t got you’re check quite
right. You ask whether the object ActionController::Base (ie the
class) responds to that method and it doesn’t so that will always
return false. What you want is whether instances of that class
respond_to your method (so this is the same as
String.respond_to? :strip returning false, “”.respond_to? :strip
returns true)

Fred


#3

Initially I had self.respond_to? but it did not work either which lead
me to believe that it might be a class problem instead of an instance
one. Is that what you are referring to?

On Jan 20, 12:52 pm, Frederick C. removed_email_address@domain.invalid


#4

On 20 Jan 2009, at 21:19, David Law wrote:

Initially I had self.respond_to? but it did not work either which lead
me to believe that it might be a class problem instead of an instance
one. Is that what you are referring to?

Not really. What I am saying is that SomeClass.respond_to? :foo
tells you whether you can do SomeClass.foo, not whether you can do
some_instance.foo

Fred


#5

On 20 Jan 2009, at 22:28, David Law wrote:

I understand that. I’m not particularly familiar with class << self
but it seems that everything within its bounds is considered a
instance method. In this case would I simply put respond_to?
(:inherited_with_facebooker)? Sorry to be bugging you so frequently,
just trying to understand this as best as I can. Thank you for all
your help.

I’d check WhateverClass.method_defined?

Fred


#6

I understand that. I’m not particularly familiar with class << self
but it seems that everything within its bounds is considered a
instance method. In this case would I simply put respond_to?
(:inherited_with_facebooker)? Sorry to be bugging you so frequently,
just trying to understand this as best as I can. Thank you for all
your help.

David

On Jan 20, 1:51 pm, Frederick C. removed_email_address@domain.invalid