August Lilleaas
2007-Dec-19 19:27 UTC
Setting @request.host in ''setup'' of functional tests borked in revision 8392
Please tell me if this has nothing to do on the rails core list. I have a feeling it does, though ; ) I''m making an app that''s using subdomains to authenticate. Hence, I set @request.host to something other than "test.host" - e.g. "clientname.local.host". However, changeset 8392 doesn''t let me set that. Here''s a pastie that should explain what happens: http://pastie.caboo.se/130596 In changeset 8391, everything works as expected. Should I do something other than @request.host=? Or is it indeed failing? Btw, e.g. @request.path= (and all other setters) is not settable either. I wish I could provide a patch, but I have no idea what''s going on =P --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
August Lilleaas
2007-Dec-19 19:38 UTC
Re: Setting @request.host in ''setup'' of functional tests borked in revision 8392
The subject of this post should have been: "''setup'' method not called in functional tests". Doing something like "raise ''lol''" in the ''setup'' method doesn''t raise on every test like one would expect it do to. On Dec 19, 8:27 pm, August Lilleaas <augustlille...@gmail.com> wrote:> Please tell me if this has nothing to do on the rails core list. I > have a feeling it does, though ; ) > > I''m making an app that''s using subdomains to authenticate. Hence, I > set @request.host to something other than "test.host" - e.g. > "clientname.local.host". > > However, changeset 8392 doesn''t let me set that. Here''s a pastie that > should explain what happens: > > http://pastie.caboo.se/130596 > > In changeset 8391, everything works as expected. Should I do something > other than @request.host=? Or is it indeed failing? > > Btw, e.g. @request.path= (and all other setters) is not settable > either. > > I wish I could provide a patch, but I have no idea what''s going on =P--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Rick Olson
2007-Dec-19 19:41 UTC
Re: Setting @request.host in ''setup'' of functional tests borked in revision 8392
On Dec 19, 11:27 am, August Lilleaas <augustlille...@gmail.com> wrote:> Please tell me if this has nothing to do on the rails core list. I > have a feeling it does, though ; ) > > I''m making an app that''s using subdomains to authenticate. Hence, I > set @request.host to something other than "test.host" - e.g. > "clientname.local.host". > > However, changeset 8392 doesn''t let me set that. Here''s a pastie that > should explain what happens: > > http://pastie.caboo.se/130596 > > In changeset 8391, everything works as expected. Should I do something > other than @request.host=? Or is it indeed failing? > > Btw, e.g. @request.path= (and all other setters) is not settable > either. > > I wish I could provide a patch, but I have no idea what''s going on =PI think there are two edge cases running head to head. You shouldn''t have to call ''super'' to use the @request variable, so it looks like it has to do with that #tests class method. Normally the tests have @request = .... in the setup, so super isn''t needed. Nor would it really do anything. I''ve passed this on to brynary, who contributed the patch in [8392], to see if we can get a solution that doesn''t involve rolling back code. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
August Lilleaas
2007-Dec-19 20:15 UTC
Re: Setting @request.host in ''setup'' of functional tests borked in revision 8392
Added a ticket for this now, after some chatter in #rubyonrails. http://dev.rubyonrails.org/ticket/10568 Next time, I''ll be patient and wait for an answer in #rails-contrib, was sorta pointless to post this is the list as well (I guess). On Dec 19, 8:41 pm, Rick Olson <technowee...@gmail.com> wrote:> On Dec 19, 11:27 am, August Lilleaas <augustlille...@gmail.com> wrote: > > > > > Please tell me if this has nothing to do on the rails core list. I > > have a feeling it does, though ; ) > > > I''m making an app that''s using subdomains to authenticate. Hence, I > > set @request.host to something other than "test.host" - e.g. > > "clientname.local.host". > > > However, changeset 8392 doesn''t let me set that. Here''s a pastie that > > should explain what happens: > > >http://pastie.caboo.se/130596 > > > In changeset 8391, everything works as expected. Should I do something > > other than @request.host=? Or is it indeed failing? > > > Btw, e.g. @request.path= (and all other setters) is not settable > > either. > > > I wish I could provide a patch, but I have no idea what''s going on =P > > I think there are two edge cases running head to head. You shouldn''t > have to call ''super'' to use the @request variable, so it looks like it > has to do with that #tests class method. Normally the tests have > @request = .... in the setup, so super isn''t needed. Nor would it > really do anything. I''ve passed this on to brynary, who contributed > the patch in [8392], to see if we can get a solution that doesn''t > involve rolling back code.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---