Re: Configuration/Initialization question

Rails Engines
1

I too am annoyed by having to restart my server frequently when editing
plugin assets. You symlink suggestion seems like it would work, but I
have a question.

Doesn’t it just end up copying all the plugin asset files on-top of
themselves at server start? If so, wouldn’t it be better to symlink and
then somehow disable the whole copy process all-together?

Trevor Rowe

2

On Mon, Aug 27, 2007 at 09:50:37AM -0700, Trevor Rowe wrote:

I too am annoyed by having to restart my server frequently when editing
plugin assets. You symlink suggestion seems like it would work, but I
have a question.

Doesn’t it just end up copying all the plugin asset files on-top of
themselves at server start? If so, wouldn’t it be better to symlink and
then somehow disable the whole copy process all-together?

I hadn’t really considered that. It wouldn’t be a problem if it did,
IMHO, but let’s look at what it really does.
See engines/lib/init.rb, at the bottom of the file in the method
mirror_files_from:

source_files.each do |file|
  begin
    target = File.join(destination, file.gsub(source, ''))
    unless File.exist?(target) && FileUtils.identical?(file, target)
      FileUtils.cp(file, target)
    end
  rescue Exception => e
    raise "Could not copy #{file} to #{target}: \n" + e
  end
end

So you see, it will never actually copy the file because it is identical
to itself. (this method is called in engines/lib/engines/plugin.rb by
mirror_public_assets)

Regards,
Peter B.
Solide ICT - http://www.solide-ict.nl

3

Hi,

Is there a special trick to getting observers to work with engines?

Putting config.active_record.observers = :my_model_observer in the
Initializer.run block throws an unitialized constant MyModelObserver
error.

The my_model_observer.rb file is in vendor/plugins/my_plugin/app/models,
alongside the model being observered, my_model.rb.

Tekin

4

On 8/29/07, Tekin S. [email protected] wrote:

Is there a special trick to getting observers to work with engines?

You should be able to do this - the observers aren’t processed until
after plugins are loaded (check railties/lib/initializer.rb to be
sure).

What this might mean is that there’s some error in either your model
or your observer file that’s causing a silent failure when the class
is loaded. I saw this recently when a model depended on a file that
wasn’t required until the bottom of environment.rb - because the
observer caused the model to be loaded before the rest of
environment.rb had been processed, but the code which the model
depended on hadn’t been loaded yet, it would silently fall over and
the problem looked like it was in the observer.

Double check that everything your model needs is required before it’s
class definition - this might help.

5

On Wed, Aug 29, 2007 at 11:47:39AM +0100, James A. wrote:

What this might mean is that there’s some error in either your model
or your observer file that’s causing a silent failure when the class
is loaded. I saw this recently when a model depended on a file that
wasn’t required until the bottom of environment.rb - because the
observer caused the model to be loaded before the rest of
environment.rb had been processed, but the code which the model
depended on hadn’t been loaded yet, it would silently fall over and
the problem looked like it was in the observer.

Yeah, Rails has the nasty habit of sometimes eating up exceptions.
Then everything seems fine until much later when something fails for
some inexplicable reason.

Sometimes running script/console reveals these errors by displaying
a message somewhere. Other times, it does not. Try removing the
observer loading statement and run script/console and refer to
the class. That should trigger it to autoload, and if there’s an
error it will show up. Rails only drops errors in some circumstances,
not in others.

By the way: Please don’t start a new topic by replying to another one.
This confuses mailclients that support threading. (replying causes
your mailclient to set an In-Reply-To header which tells my client
that this is a reply in the previous thread and it displays it as
such)

Regards,
Peter B.
Solide ICT - http://www.solide-ict.nl

6

On 8/29/07, Peter B. [email protected] wrote:

Sometimes running script/console reveals these errors by displaying
a message somewhere. Other times, it does not. Try removing the
observer loading statement and run script/console and refer to
the class. That should trigger it to autoload, and if there’s an
error it will show up. Rails only drops errors in some circumstances,
not in others.

You’ll need to be careful in this case, because it’s the fact that the
observer causes the model to be loaded before the rest of
environment.rb has been processed that could be causing the problem.

But, yes, script/console is your friend. You could also try commenting
out anything after the end of the initializer block to see if your
model has any hidden dependencies that it isn’t explicitly declaring.

7

Try removing the observer loading statement and run script/console
and refer to the class.

That should trigger it to autoload, and if there’s an error it will
show up.

Rails only drops errors in some circumstances, not in others.

This was the first thing I tried, both the model and the observer load
fine at the console.

By the way: Please don’t start a new topic by replying to another
one.

This confuses mailclients that support threading. (replying causes
your mailclient to set an In-Reply-To header which tells my client
that this is a reply

in the previous thread and it displays it as such)

Apologies, will remember this in future.

8

Double check that everything your model needs is required before it’s

class definition - this might help.

I tried again, clearing the model so it was an empty, vanilla
ActiveRecord model and still got the error.

One thing that may or may not be unusual, the error is being thrown
during the loading of the first plugin, which is not the one containing
the observer or the observered model:

loading plugin from script/…/config/…/vendor/plugins/raid_core with
engine additions
Exiting
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support
/dependencies.rb:266:in `load_missing_constant’: uninitialized constant
MyModelObserver (NameError)

9

OK, so I thought I’d go back to basics, fresh empty rails app with a
single empty engines enable plugin and still no joy.

With my_model.rb and my_model_observer.rb in app/models, everything
starts up fine. If I move them to vendor/plugins/testplugin/app/models,
I get the same unitialized constant error.

I then tried it without specifying the plugin load order (config.plugins
= [‘engines’, ‘*’]) and there is no error, despite the plugins loading
in the same order. If I explicitly specify the plugin (config.plugins =
[‘engines’, ‘testplugin’]), it also works.

Same applies to my app, with the plugin explicitly listed in the config,
it now works.

Is this expected behaviour?

10

On 8/29/07, Tekin S. [email protected] wrote:

One thing that may or may not be unusual, the error is being thrown
during the loading of the first plugin, which is not the one containing
the observer or the observered model:

loading plugin from script/…/config/…/vendor/plugins/raid_core with
engine additions
Exiting
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support
/dependencies.rb:266:in `load_missing_constant’: uninitialized constant
MyModelObserver (NameError)

At this point, I’d probably recommend throwing puts statements around
every line in the init.rb file of the plugin that causes the error, so
we can trace which line of code is causing the actual problem…

11

behaviour, the engines plugin actually defers loading of any plugins
that weren’t specified

manually by using the after_initialize mechanism. You’re seeing a
problem because, when

using that star-syntax, at the point where Rails is trying to
instantiate your observer your

testplugin hasn’t been loaded yet.

OK, that makes sense, thanks.

12

On 8/29/07, Tekin S. [email protected] wrote:

I then tried it without specifying the plugin load order (config.plugins
= [‘engines’, ‘*’]) and there is no error, despite the plugins loading
in the same order. If I explicitly specify the plugin (config.plugins =
[‘engines’, ‘testplugin’]), it also works.

Is this expected behaviour?

Aaaaah. OK. Here’s what’s happening.

To support the

config.plugins = %w(engines *)

behaviour, the engines plugin actually defers loading of any plugins
that weren’t specified manually by using the after_initialize
mechanism. You’re seeing a problem because, when using that
star-syntax, at the point where Rails is trying to instantiate your
observer your testplugin hasn’t been loaded yet.

The solution, for the moment, is to just add your observer-containing
plugins explicitly to config.plugins - that way they will definitely
be available before Rails starts dealing with observers. Another
solution would be to call YourObserverClass.instance at the bottom of
environment.rb, rather than using config.observers - either will work
fine.