Initializer does not work with Rails 5?

[netsensei]

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:

1. Install a new Rails app with rails new myapp
2. Add the riiif gem in Gemfile
3. Run `bundle install``
4. Add the riiif engine to routes.rb
5. create a new initializer app/config/initializers/riiif.rb
6. Now add this line: Riiif::Image.file_resolver.base_path = '/vagrant/images/' (change the file store)
7. 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!

[jcoyne]

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

[netsensei]

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!

[netsensei]

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]

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]

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

[netsensei]

@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]

@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]

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

[mejackreed]

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

[mcritchlow]

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.

[benwbrum]

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