Forum: Ruby on Rails (BUG in svn/trunk?) - superclass mismatch for any subclass o

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Miles K. (Guest)
on 2006-02-03 09:40
(Received via mailing list)
I track svn/trunk of Rails using svn:externals

Some change to Rails committed in the last 1-2 days broke my subclass
of ApplicationController

The example, below, works with Rails 1.0, but in today's svn, it dies
with the following error:

"superclass mismatch for class FooController"

class ApplicationController < ActionController::Base
end

class FooController < ApplicationController
end


The reason I'm emailing the list instead of filing a bug report is to
see if anyone knows if this change was intentional.  I hope not,
because I really do need to have a subclass of ApplicationController.

Any advice appreciated.


- Miles
Francois B. (Guest)
on 2006-02-03 09:46
(Received via mailing list)
Hello Miles,

2006/2/3, Miles K. <removed_email_address@domain.invalid>:
> I track svn/trunk of Rails using svn:externals

I do the same.

> Some change to Rails committed in the last 1-2 days broke my subclass
> of ApplicationController

Actually, I tracked it down to r3524.  If I load r3523, my app works
fine, if r3524, I get the following backtrace:

NameError: constant Object::ApplicationController not defined
  ./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/class/removal.rb:14:in
`remove_const'
  ./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/class/removal.rb:14:in
`send'
  ./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/class/removal.rb:14:in
`remove_class'
  ./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/class/removal.rb:11:in
`each'
  ./script/../config/../vendor/rails/activesupport/lib/active_support/core_ext/class/removal.rb:11:in
`remove_class'
  ./script/../config/../vendor/rails/railties/lib/dispatcher.rb:56:in
`reset_application!'
  ./script/../config/../vendor/rails/railties/lib/dispatcher.rb:74:in
`reset_after_dispatch'
  ./script/../config/../vendor/rails/railties/lib/dispatcher.rb:46:in
`dispatch'
  ./script/../config/../vendor/rails/railties/lib/webrick_server.rb:117:in
`handle_dispatch'
  ./script/../config/../vendor/rails/railties/lib/webrick_server.rb:83:in
`service'
  C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
  C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:155:in `start_thread'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start_thread'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:94:in `start'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:89:in `each'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:89:in `start'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start'
  C:/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start'
  ./script/../config/../vendor/rails/railties/lib/webrick_server.rb:69:in
`dispatch'
  ./script/../config/../vendor/rails/railties/lib/commands/servers/webrick.rb:59
  C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in
`require__'
  C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in
`require'
  ./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:283:in
`require'
  ./script/../config/../vendor/rails/railties/lib/commands/server.rb:28
  C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in
`require__'
  C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in
`require'
  script/server:3

This is a different bug than yours, but it seemed related enough that
I'd mention it here.

Bye !
Ben M. (Guest)
on 2006-02-03 20:01
(Received via mailing list)
I could swear I saw this exact problem on the list in the last week or
so... give the
archives a search...

b
Sam S. (Guest)
on 2006-02-03 20:07
(Received via mailing list)
Hi Miles,

On 2/3/06, Miles K. <removed_email_address@domain.invalid> wrote:
> class ApplicationController < ActionController::Base
> Any advice appreciated.
>

Yep, trunk is broken at the moment. For now I'd suggest rolling back
to revision 3479.

To do this, run "svn propedit svn:externals vendor" from your
application's directory. Then change the line that reads

  rails http://dev.rubyonrails.com/svn/rails/trunk

to

  rails -r3479 http://dev.rubyonrails.com/svn/rails/trunk

and svn up.

--
sam
David Heinemeier H. (Guest)
on 2006-02-04 19:21
(Received via mailing list)
> > Some change to Rails committed in the last 1-2 days broke my subclass
> > of ApplicationController
> >
> > The example, below, works with Rails 1.0, but in today's svn, it dies
> > with the following error:

Trunk has now been fixed.
--
David Heinemeier H.
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
This topic is locked and can not be replied to.