report back on "A copy of ApplicationController has been removed from the module tree but is still active!"

[Jason Ronallo]

Hi,
At the last committers meeting I was asked to report back about a kind
of error that creeps in intermittently in development mode when using
engines. You might have seen errors like the following:

"A copy of ApplicationController has been removed from the module tree
but is still active!"
"can’t dup NilClass"

The old and deprecated fix for this was to add "unloadable" to the
proper model or controller. Sometimes this seems to need to be done
within the plugin.
http://robots.thoughtbot.com/post/159805560/tips-for-writing-your-own-rails-engine
http://groups.google.com/group/blacklight-development/browse_thread/thread/1f00bff8d8a26a83/b54d866e221e5030?hl=en&lnk=gst&q=unloadable#b54d866e221e5030

Here's a post about this issue that lists various work arounds instead
of the now deprecated "unloadable":
http://strd6.com/?p=250

Two possibilities are suggested:

1. Change the init.rb within the plugin to include the following:
load_paths.each do |path|
ActiveSupport::Dependencies.load_once_paths.delete(path)
end if config.environment == 'development'

2. Change environment.rb to include the following:
config.reload_plugins = true if RAILS_ENV == 'development'

Since our method of installation is changing, I decided to try each of
these methods by using the template. I used to template to get a full
demo application. I then overrode the index action in the catalog
controller. Unfortunately I was unable to reproduce the original
error. I went ahead and made each change in any case.

With #1 I got a new error. So there's no way I'm going to apply that.

With #2 I did not get a new error, but then again I wasn't able to
reproduce the original error either. But because this error seems to
creep in intermittently and unexpectedly, I think there is no big harm
in adding it. This would slow down requests in development mode since
the plugins are completely reloaded each time. But since I can't
currently reproduce the error, I don't know whether I ought to add it
or not.

Can anyone reproduce the "A copy of ApplicationController has been
removed from the module tree but is still active!" error?

Proposal: If someone else can't reproduce this error then we could
just add something to the documentation about possible fixes if this
error does creep in. This might belong in "Customizing Blacklight"
documentation since, from what I've read, it doesn't appear unless a
Controller or Model has been added/overridden.

Thoughts?

Jason

[Jessie Keck]

Hi Jason,
Not sure if anybody has responded to you on this or not.

Anytime I include a module from the helper I can reproduce this error
when running under development mode.

Try this, create a module called MyModule with a constant.
Have a method in the ApplicationHelper call the constant in MyModule
Have a view call the helper method from the show view

Start the app, bring up a record. Refresh, and viola! ( I get "A copy
of ApplicationHelper has been removed from the module tree but is
still active!" )

In case my above explanation wasn't clear, check this out:
module MyModule
CONST = "SOME TEXT"
end

module AplicationHelper
def some_method
MyModule::CONST
end
end

in _show_partials/_default.html.erb:
<%= some_method %>

I have run into this several times using different methods of calling
other modules from the ApplicationHelper module. The above case is
just an uber-simplified version of some of the things I have run into.

Not sure if this helps, or will shed any light on what is going on
with this problem, but I thought I would post this to the list as it
is something that we have run into in the past and just had to make
programming decisions on how to deal with it in another way.

BTW, your suggestion below of: config.reload_plugins = true if
RAILS_ENV == 'development' did not work for this case.
- Jessie

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Blacklight Development" group.
> To post to this group, send email to blacklight-...@googlegroups.com
> To unsubscribe from this group, send email to blacklight-develo...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

[Ron DuPlain]

On Thu, Oct 29, 2009 at 11:01 AM, Jason Ronallo <jron...@gmail.com> wrote:
> At the last committers meeting I was asked to report back about a kind
> of error that creeps in intermittently in development mode when using
> engines. You might have seen errors like the following:
>
> "A copy of ApplicationController has been removed from the module tree
> but is still active!"
> "can’t dup NilClass"
>

I am consistently seeing:

"A copy of ApplicationController has been removed from the module tree
but is still active!"

I did see "can’t dup NilClass" once while trying to triage the first
error (ApplicationController).

> Here's a post about this issue that lists various work arounds instead
> of the now deprecated "unloadable":
> http://strd6.com/?p=250
>
> Two possibilities are suggested:
>
> 1. Change the init.rb within the plugin to include the following:
> load_paths.each do |path|
>    ActiveSupport::Dependencies.load_once_paths.delete(path)
> end if config.environment == 'development'
>
> 2. Change environment.rb to include the following:
> config.reload_plugins = true if RAILS_ENV == 'development'
>

I found no luck with fix #2. In environment.rb, I set:

config.reload_plugins = true

This is great for the first refresh after seeing the
ApplicationController error (it works... once). All subsequent
responses result in another error:

NoMethodError in CatalogController#index

You have a nil object when you didn't expect it!
You might have expected an instance of ActiveRecord::Base.
The error occurred while evaluating nil.[]

> Since our method of installation is changing, I decided to try each of
> these methods by using the template. I used to template to get a full
> demo application. I then overrode the index action in the catalog
> controller. Unfortunately I was unable to reproduce the original
> error. I went ahead and made each change in any case.

[snip]

> Can anyone reproduce the "A copy of ApplicationController has been
> removed from the module tree but is still active!" error?
>

I did install blacklight v2.4.0 from github a couple weeks ago on
another host without any issues, so now I'm looking into what's
different between the hosts and projects.

I'll report back if I find anything.

-Ron

[Jonathan Rochkind]

Yeah, I keep running into those sorts of things too, and also haven't
been able to fix them. If all else fails, you can always simply turn
off class reloading in development. put "config.cache_classes = false"
into your development.rb. That'll definitely fix the problem, at the
cost of eliminating class reloading in development, of course.

Class reloading sounds nice, but in my other Rails projects it
frequently fails too, I generally end up turning it off.

Ron DuPlain wrote:
> On Thu, Oct 29, 2009 at 11:01 AM, Jason Ronallo <jron...@gmail.com> wrote:
>
>> At the last committers meeting I was asked to report back about a kind
>> of error that creeps in intermittently in development mode when using
>> engines. You might have seen errors like the following:
>>
>> "A copy of ApplicationController has been removed from the module tree
>> but is still active!"

>> "can�t dup NilClass"

>>
>>
>
> I am consistently seeing:
>
> "A copy of ApplicationController has been removed from the module tree
> but is still active!"
>

> I did see "can�t dup NilClass" once while trying to triage the first

> --

>
> You received this message because you are subscribed to the Google Groups "Blacklight Development" group.

> To post to this group, send email to blacklight-...@googlegroups.com.
> To unsubscribe from this group, send email to blacklight-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
>
>
>
>

[Matt Mitchell]

Be sure to try out what's in master now -- we need to get that out as 2.4.1 which I can do this week.

Matt

On Tue, Dec 1, 2009 at 11:57 AM, Jonathan Rochkind <roch...@jhu.edu> wrote:

Yeah, I keep running into those sorts of things too, and also haven't
been able to fix them.   If all else fails, you can always simply turn
off class reloading in development. put "config.cache_classes = false"
into your development.rb.  That'll definitely fix the problem, at the
cost of eliminating class reloading in development, of course.

Class reloading sounds nice, but in my other Rails projects it
frequently fails too, I generally end up turning it off.

Ron DuPlain wrote:
> On Thu, Oct 29, 2009 at 11:01 AM, Jason Ronallo <jron...@gmail.com> wrote:
>
>> At the last committers meeting I was asked to report back about a kind
>> of error that creeps in intermittently in development mode when using
>> engines. You might have seen errors like the following:
>>
>> "A copy of ApplicationController has been removed from the module tree
>> but is still active!"

>> "can’t dup NilClass"

>>
>>
>
> I am consistently seeing:
>
> "A copy of ApplicationController has been removed from the module tree
> but is still active!"
>

> I did see "can’t dup NilClass" once while trying to triage the first

[Ron DuPlain]

On Tue, Dec 1, 2009 at 11:57 AM, Jonathan Rochkind <roch...@jhu.edu> wrote:

> Yeah, I keep running into those sorts of things too, and also haven't
> been able to fix them.   If all else fails, you can always simply turn
> off class reloading in development. put "config.cache_classes = false"
> into your development.rb.  That'll definitely fix the problem, at the
> cost of eliminating class reloading in development, of course.
>

You mean "config.cache_classes = true", right?

> Class reloading sounds nice, but in my other Rails projects it
> frequently fails too, I generally end up turning it off.
>

WIth "config.cache_classes = true" the ApplicationController fail goes
away, but at the cost of neglecting changes I have in
ApplicationHelper. My guess is that
vendor/plugins/blacklight/app/helpers/application_helper.rb is being
cached (and app/helpers/application_helper.rb is not read). The only
change I have is application_name so it's not a big loss.

On Tue, Dec 1, 2009 at 11:59 AM, Matt Mitchell <good...@gmail.com> wrote:
> Be sure to try out what's in master now -- we need to get that out as 2.4.1
> which I can do this week.
>

I'll try that, too.
Thanks,

Ron

> Ron DuPlain wrote:
>> On Thu, Oct 29, 2009 at 11:01 AM, Jason Ronallo <jron...@gmail.com> wrote:
>>
>>> At the last committers meeting I was asked to report back about a kind
>>> of error that creeps in intermittently in development mode when using
>>> engines. You might have seen errors like the following:
>>>
>>> "A copy of ApplicationController has been removed from the module tree
>>> but is still active!"

>>> "can’t dup NilClass"

>>>
>>>
>>
>> I am consistently seeing:
>>
>> "A copy of ApplicationController has been removed from the module tree
>> but is still active!"
>>

>> I did see "can’t dup NilClass" once while trying to triage the first

[Jonathan Rochkind]

Ron DuPlain wrote:
>
> You mean "config.cache_classes = true", right?
>

Yes, sorry, exactly.

>
>
>> Class reloading sounds nice, but in my other Rails projects it
>> frequently fails too, I generally end up turning it off.
>>
>>
>
> WIth "config.cache_classes = true" the ApplicationController fail goes
> away, but at the cost of neglecting changes I have in
> ApplicationHelper.

Wait, you don't just mean neglecting changes you made after you started
the app, you mean you don't get your changes at _all_? You're talking
about a local ApplicationHelper right? That IS a big problem, in my
opinion.

Aha, this is because there's something weird going on with Engines and
ApplicationHelper that I don't think we've ever gotten to the bottom of.
BUT I think someone DID figure out the solution: At the top of your
local ApplicationHelper add:

require_dependency(RAILS_ROOT +
"vendor/plugins/blacklight/app/helpers/application_helper.rb")

I wonder if that'll fix your original problem with class-unloading too.
But it's actually a _bigger_ warning sign if your local
applicationhelper is being ignored, that means something ain't right.
And that config.cache_classes effects this is awfully confusing to me,
but I guess is the result of something weird going on with class
reloading; sadly, Rails class reloading, in my experience, especially in
an environment of many plugins and gems, and especially in an
environment of Engines, often leads to really weird problems that
require learning way more about ruby/Rails internals then I want to know
to solve.

Jonathan

> My guess is that
> vendor/plugins/blacklight/app/helpers/application_helper.rb is being
> cached (and app/helpers/application_helper.rb is not read). The only
> change I have is application_name so it's not a big loss.
>
>

It's a big loss to me, it's important that you are able to change
behavior by over-riding helper methods, that's the point of the Engine
plugin.

[Ron DuPlain]

On Tue, Dec 1, 2009 at 12:55 PM, Jonathan Rochkind <roch...@jhu.edu> wrote:
> Ron DuPlain wrote:
>> WIth "config.cache_classes = true" the ApplicationController fail goes
>> away, but at the cost of neglecting changes I have in
>> ApplicationHelper.
>
> Wait, you don't just mean neglecting changes you made after you started
> the app, you mean you don't get your changes at _all_? You're talking
> about a local ApplicationHelper right?  That IS a big problem, in my
> opinion.
>

Yes, that's right. My development server isn't picking up my local
ApplicationHelper at start (regardless of reload) with
config.cache_classes = true.

> Aha, this is because there's something weird going on with Engines and
> ApplicationHelper that I don't think we've ever gotten to the bottom of.
> BUT I think someone DID figure out the solution:  At the top of your
> local ApplicationHelper add:
>
> require_dependency(RAILS_ROOT +
> "vendor/plugins/blacklight/app/helpers/application_helper.rb")
>

With this, I get my local ApplicationHelper:

require_dependency(RAILS_ROOT +
"/vendor/plugins/blacklight/app/helpers/application_helper.rb")

^

(Note that you need a path separator '/' here.)

> I wonder if that'll fix your original problem with class-unloading too.

No, it doesn't fix it.
Thanks for the tips,

Ron

> But it's actually a _bigger_ warning sign if your local
> applicationhelper is being ignored, that means something ain't right.
> And that config.cache_classes effects this is awfully confusing to me,
> but I guess is the result of something weird going on with class
> reloading; sadly, Rails class reloading, in my experience, especially in
> an environment of many plugins and gems, and especially in an
> environment of Engines, often leads to really weird problems that
> require learning way more about ruby/Rails internals then I want to know
> to solve.
>
> Jonathan
>
>
>> My guess is that
>> vendor/plugins/blacklight/app/helpers/application_helper.rb is being
>> cached (and app/helpers/application_helper.rb is not read).  The only
>> change I have is application_name so it's not a big loss.
>>
>>
>
> It's a big loss to me, it's important that you are able to change
> behavior by over-riding helper methods, that's the point of the Engine
> plugin.
>
>

[Jonathan Rochkind]

Hmm, I'm out of ideas, but I'd focus on the "not picking up your local
ApplicationHelper problem." Because if it doesn't do that with
config.cache_classes = true, that means it won't do it in production
either. Which would be a problem. It's definitely the intent of the BL
plugin that you should be able to over-ride helper methods in your local
app, that's kind of important.

[Ron DuPlain]

I should clarify. Things work with (in development.rb)

config.cache_classes = true

AND I get my local ApplicationHelper with (in app/helpers/application_helper.rb)

require_dependency(RAILS_ROOT +
"/vendor/plugins/blacklight/app/helpers/application_helper.rb")

Thanks,

Ron