Rails 3.1をオーバーライドする方法 "globing route"エンジンを使用する場合の "Routing Error"？

Question

私は従来のアプリをRails 3.1に変換しています。レガシーアプリはそう比類のないルートに（というおなじみのRailsよりも、「ルーティングエラー」ページ）をカスタムハンドリングを提供するために、最終的なキャッチオールワイルドカードのルートを使用

# myengine/config/routes.rb 
Rails.application.routes.draw do 
    match 'foo/bar/*path' => 'myengine/foobar#index', :format => false 
end 

：新しいアプリはグロブルートを提供してエンジンを使用しています

# myapp/config/routes.rb 
Myapp::application.routes.draw do 
    # ... 
    match '*path' => 'failures#index', :format => false 
end 

何とかこのキャッチオールルートがエンジンのルートを妨害しています。アプリのキャッチオールルートをコメントアウトすると、エンジンのルートが正常に動作します。しかし、私はマッチされることはありませんエンジンのルートでそれを残し、failures#indexへのアプリのキャッチオールルートが代わりに使用されている場合：

Started GET "/foo/bar//projects/x/vol1/prod22/9907042031/9907042031.aff/ImageProperties.xml" for 10.71.1.136 at 2011-08-02 15:46:48 -0700 
    Processing by FailuresController#index as JS 
    Parameters: {"path"=>"foo/bar/projects/x/vol1/prod22/9907042031/9907042031.aff/ImageProperties.xml"} 
Rendered failures/index.html.erb within layouts/application (0.0ms) 
Completed 200 OK in 47ms (Views: 46.9ms) 

どのようにしてエンジンのルートを壊すことなく、デフォルトのRails 3.1ルーティングエラーハンドラをオーバーライドするでしょうか？

Answer 1

は、エンジンに敵対的なcatchallルートではなく、rescue_fromとカスタムエラーハンドラを処理する正しい方法です。しかし、custom error handlers are no longer supported in Rails 3.1とこれはRails 3.2まで修正されていない可能性があります。カスタムエラー処理が必要で、ルートのあるエンジンを使用する場合は、vidibus-routing_error gemが回避策を提供します。

カスタムエラーハンドラをスタックの一番下にあるRackエンドポイントに配置することもできます。