Initializer does not work with Rails 5?

Question

Initializer does not work with Rails 5?

netsensei opened this issue 6 years ago · comments

Matthias Vandermaesen commented 6 years ago

Hi,

I'm trying to get the riiif gem working on a barebones Rails 5.2.0 application with one controller/action. I'm doing this just to get a feeling for how this gem works.

My problem: When I try to add the configuration in an initialiser, riiif/rails still falls back to the defaults in the original gem code.

How to reproduce:

Install a new Rails app with rails new myapp
Add the riiif gem in Gemfile
Run `bundle install``
Add the riiif engine to routes.rb
create a new initializer app/config/initializers/riiif.rb
Now add this line: Riiif::Image.file_resolver.base_path = '/vagrant/images/' (change the file store)
Start the server with rails s

Add a picture and then navigate to the IIIF URL where riiif would serve said picture. This is where I get this error message:

Riiif::ImageNotFoundError in Riiif::ImagesController#show

/vagrant/railsapp/tmp/0000_GRO0026_I.{png,jpg,tif,tiff,jp2}

Extracted source (around line #28):

    def path(id)
      search = pattern(id)
      search && Dir.glob(search).first || raise(ImageNotFoundError, search)
    end

    def pattern(_id)

Notice how riiif isn't looking in /vagrant/images but instead in the app/tmp folder of the rails application itself.

I've traced the code down to the Riiif::Image module. This is where the file_resolver is set with a default FileSystemFileResolver with a base_path which resolves to app/tmp.

So, I guess my question is: how can I properly override the attribute / leverage the accessor in that module via an initializer with Rails 5.2.0?

Thanks!

Justin Coyne · Answer 1 · Sat Apr 14 2018 06:16:11 GMT+0800 (China Standard Time)

Can you try doing:

Riiif::Image.file_resolver = FileSystemFileResolver.new(base_path: '/vagrant/images')

It looks like there may be a documentation error in the README. Here's what I've used recently: https://github.com/sul-dlss-labs/image-server/blob/master/config/initializers/riiif.rb#L1

Matthias Vandermaesen · Answer 2 · Sun Apr 15 2018 04:58:04 GMT+0800 (China Standard Time)

Tried your first suggestion. The problem persists. I also tried with the StacksFileResolver service as an initializer. That was also ignored.

I've cloned the sul-dlss-labs/image-server repo on my Vagrant box (Debian 8). I've got it up and running but I see the same error pop up. During installation, I first did a simple bundle install to get all the Gemfile deps. That triggered Rails errors since those refer to older versions of gems which aren't compatible with Rails 5.2.0. So, I first did a bundle update and a bundle install --force to get the correct versions. Then I changed the line in riiif.rb to your suggestion: no luck so far.

Could you tell me what version of Rails / Ruby you are on? Over here, it's Rails 5.2.0 with Ruby 2.4.1. I could try downgrading my versions to match with what you are using.

I'm also using nginx + phusion passenger as a proxy.

Thanks!

Matthias Vandermaesen · Answer 3 · Tue Apr 17 2018 19:53:38 GMT+0800 (China Standard Time)

Quick update. I just ran the rails app with the standalone rails server. This works as normally. Seems like the culprit is either Passenger or Nginx.

Teifun2 · Answer 4 · Sat Feb 23 2019 02:19:23 GMT+0800 (China Standard Time)

I have the same problem. Curiously with my setup the error arises much later. So i can load images with riiif and the Engine works. After some time the exact same image is not available anymore. And the riiif Engine is looking for the images in the tmp folder.
Any idea on how to fix this?
(i also run with passenger)

KingNoah · Answer 5 · Mon May 11 2020 21:57:02 GMT+0800 (China Standard Time)

@netsensei @Teifun2 Did you find a fix for this? I'm running into a similar issue with Riiif and Docker

Matthias Vandermaesen · Answer 6 · Mon May 11 2020 23:05:59 GMT+0800 (China Standard Time)

@KingNoah Are you using passenger? Because I didn't use passenger and went with puma (rails server) instead.

I opened up an issue in the passenger issue queue... which is still active and has a reference to a "smart spawning" as a potential culprit:
phusion/passenger#2066

Teifun2 · Answer 7 · Tue May 12 2020 15:44:50 GMT+0800 (China Standard Time)

@KingNoah Sadly i was not able to fix it. I just restart the server whenver it happens and then have a time window where the iamges are loaded normally.

KingNoah · Answer 8 · Tue May 12 2020 22:40:35 GMT+0800 (China Standard Time)

Thanks @netsensei, switching to Puma seems to have fixed the issue for us as well. Switching may help you as well, @Teifun2

Jack Reed · Answer 9 · Tue May 12 2020 22:44:50 GMT+0800 (China Standard Time)

Did anyone on this thread try using this branch? #134

Matthew Critchlow · Answer 10 · Thu Jun 11 2020 04:58:42 GMT+0800 (China Standard Time)

Just dropping this here, as it might be of use to others, not sure. I tried #134 and it didn't help in our situation, which is where the sidekiq workers trying to run a spotlight csv ingest were failing to get the file_resolver we were setting in our initializer (in our case, CarrierWave) and were falling back on the default.

Wrapping the initializer code with an ActiveSupport::Reloader.to_prepare block solved the problem, at least as far we've been able to tell so far.

Ben W. Brumfield · Answer 11 · Sun Jan 17 2021 22:39:53 GMT+0800 (China Standard Time)

We ran into the same problem after an upgrade from Rails 4 to Rails 6. In our case, our production environment (Apache/Passenger) was loading our custom resolver correctly, but our development environment (rails server/Puma) ignored or overwrote our initialization code and used the default instead.

The #134 branch didn't help, but using @mcritchlow's suggestion worked: benwbrum/fromthepage@8f7fc9a