One is defined like:
class Partner::LoginController < ApplicationController
end
The other is defined like:
class LoginController < ApplicationController
end
Wonder if wrapping the other in module Partner instead of prefixing
the classname with the module would have any effect...
-John
On Nov 24, 1:02 pm, Frederick Cheung <[EMAIL PROTECTED]>
wrote:
> On 24 Nov 2008, at 17:41, John Trupiano wrote:
>
>
>
> > Also, worth noting that the app is running rails 2.1.0 currently. I
> > also had this problem when it was previously running 2.0.2. Upgrading
> > to 2.1.2 is potentially an option, but I'm wary of just trying
> > something like that in production when I don't fully understand what
> > the problem is, so I'm holding off on that in the meantime.
>
> Are the classes both named LoginController or is one of them
> Partner::LoginController ?
>
> Fred
>
>
>
> > -John
>
> > On Nov 24, 12:39 pm, John Trupiano <[EMAIL PROTECTED]> wrote:
> >> Hi, I've been battling a very strange and irritating bug for a long
> >> time now. The issue is the following:
>
> >> I have namespaced my controllers in routes.rb
> >> * map.resources :login, :collection => [:login, :logout]
> >> * map.namespace :partner do |p|
> >> p.resources :login, :collection => [:login, :logout]
> >> end
>
> >> As such, I have two distinct controllers app/controllers/
> >> login_controller and app/controllers/partner/login_controller.
>
> >> I'm running Apache + Passenger 2.0.3. When apache is freshly
> >> restarted, requests to /partner/login invoke the proper controller.
> >> However, after some period of time (or some series of
> >> actions....whatever it is, I cannot isolate it), the wrong controller
> >> will be invoked when requesting /partner/login.
>
> >> Reaching back into my logs, I see no difference in the logging that
> >> rails performed.
>
> >> *** Log entry before bug starts showing up
>
> >> Processing LoginController#index (for xx.xx.xx.xx at 2008-11-24
> >> 10:33:26) [GET]
> >> Session ID: bb63a070c1fa56a703018fa922359146
> >> Parameters: {"action"=>"index", "controller"=>"partner/login"}
> >> Rendering template within layouts/application
> >> Rendering partner/login/index
> >> Completed in 0.00188 (531 reqs/sec) | Rendering: 0.00178 (94%) | DB:
> >> 0.00180 (95%) | 200 OK [https://myapp/partner/login]
>
> >> *** Log entry after bug has started showing up
>
> >> Processing LoginController#index (for xx.xx.xx.xx at 2008-11-24
> >> 12:26:35) [GET]
> >> Session ID: 5bdeff99bd72fe94cb8b80fd9b6beff6
> >> Parameters: {"action"=>"index", "controller"=>"partner/login"}
> >> Rendering template within layouts/static_dashboard
> >> Rendering login/index
> >> Completed in 0.00286 (349 reqs/sec) | Rendering: 0.00274 (95%) | DB:
> >> 0.00429 (150%) | 200 OK [https://myapp/partner/login]
>
> >> What kills me is that in parameters, the proper controller/action are
> >> being identified. But if you look at the succeeding lines, you'll
> >> see
> >> different templates being rendered.
>
> >> This has been happening to me for quite a while. Even prior to
> >> moving
> >> to Passenger quite a while ago, I saw this same bug crop up in
> >> production when using a mongrel_cluster solution behind Pound. So
> >> I'm
> >> fairly certain that it's not related to Passenger. I have not seen
> >> it
> >> arise in my local dev environment (running mongrel).
>
> >> I realize this is quite the shot in the dark, but I was curious if
> >> anyone had any thoughts whatsoever on the source of this problem, or
> >> if you've encountered anything similar in the past.
>
> >> Thanks for any help.
>
> >> -John
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
