Calling mount and resource inside the router makes mount stop working

Seems a lot similar to this one : https://rails.lighthouseapp.com/projects/8994/tickets/4478-impossib...

This is a weird one - the resource call can be before or after the mount and it works if the resource call is nested inside a resources call but not inside a namespace. I've tried renaming the resource method but that didn't work. Inspecting the scope before and after the resource call shows a bunch of nil values in the scope but they're exactly the same as a resources call.

If you turn off all the routes using :only => [], then it works. You can also make a resources call generate the error by doing :only => [:show, :new, :create]. I think the error must be in rack-mount somewhere.

Works for me.

Make sure you're using Sinatra 1.x, needs to include this commit http://github.com/sinatra/sinatra/commit/f9a792396ca6172e983b7eb4d7...

Still getting the problem here when using Sinatra 1.0. It's triggered by defining a singleton resource at the top level. If you nest the resource then it works. However namespacing the resource doesn't fix it.

I followed the call down into Rack::Mount with ruby-debug but didn't follow it any further. I'll do some more investigation tonight.

It looks as though the problem is somewhere in Rack::Mount::Analysis::Splitting.

This is what I get for @recognition_key_analyzer.possible_keys when using resource:

[
  {path_info[0]=>"/blog"}, 
  {:request_method=>/POST/, path_info[0]=>"/user"}, 
  {:request_method=>/GET/, path_info[0]=>"/user/new"}, 
  {:request_method=>/GET/, path_info[0]=>"/user"}, 
  {:request_method=>/PUT/, path_info[0]=>"/user"}, 
  {:request_method=>/DELETE/, path_info[0]=>"/user"}, 
  {:request_method=>/GET/, path_info[0]=>"/user/edit"}, 
  {path_info[0]=>"/rails/info/properties", path_info[1]=>"\000"}
]

And this is what I get for @recognition_key_analyzer.possible_keys when using resources:

[
  {path_info[0]=>"blog"}, 
  {:request_method=>/GET/, path_info[0]=>"users"}, 
  {:request_method=>/POST/, path_info[0]=>"users"}, 
  {:request_method=>/GET/, path_info[0]=>"users", path_info[1]=>"new"}, 
  {:request_method=>/GET/, path_info[0]=>"users", path_info[1]=>/\A([^\/.?]+)\Z/}, 
  {:request_method=>/PUT/, path_info[0]=>"users", path_info[1]=>/\A([^\/.?]+)\Z/}, 
  {:request_method=>/DELETE/, path_info[0]=>"users", path_info[1]=>/\A([^\/.?]+)\Z/}, 
  {:request_method=>/GET/, path_info[0]=>"users", path_info[1]=>/\A([^\/.?]+)\Z/, path_info[2]=>"edit"}, 
  {path_info[0]=>"rails", path_info[1]=>"info"}, path_info[2]=>"properties", path_info[3]=>"\000"
]

I'm not sure whether it's significant, but it looks like it might be.

Josh, I think I've identified the problem. When you have a small number of routes then '/' may be dropped from the separator pattern because it doesn't appear enough to put it in the upper quartile. Put in a few more routes and it then starts working. Shouldn't '/' always be in the separator pattern?