JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-6705

Error during gem loading in Rails: ActiveRecord is not missing constant Base

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.7.0.pre1
    • Fix Version/s: JRuby 1.7.0.pre2
    • Component/s: Core Classes/Modules
    • Labels:
      None
    • Environment:
      Rails 3.2.3
      Ruby 1.8 Mode
    • Number of attachments :
      1

      Description

      Starting a few weeks ago I after updating to a more recent version of JRuby-HEAD I started to notice the following error:

      "NameError: ActiveRecord is not missing constant Base!"[1]

      The error happens during the loading of one of my Gems, and also with at least one third-party gem (see stacktraces below). With JRuby 1.6 and MRI it works without problems.

      I was able to bisect it to the commit 20632af6e1fa511fd9b762beda2a60d39bf3c859. Reverting this commit fixes the problem.

      I'm not sure if this something specific to my environment, it well might be. Still I mark it as a release blocker as it a) it's hard to debug and b) makes, at least in my case, jruby unusable for rails.

      Thank you!

      Reto Schüttel

      [1] Stacktrace and files
      NameError: ActiveRecord is not missing constant Base!
      load_missing_constant at vendor/bundle/jruby/1.8/gems/activesupport-3.2.3/lib/active_support/dependencies.rb:494
      const_missing at vendor/bundle/jruby/1.8/gems/activesupport-3.2.3/lib/active_support/dependencies.rb:192
      each at org/jruby/RubyArray.java:1611
      const_missing at vendor/bundle/jruby/1.8/gems/activesupport-3.2.3/lib/active_support/dependencies.rb:190
      (root) at vendor/bundle/jruby/1.8/gems/meta_search-1.1.3/lib/meta_search.rb:55
      require at org/jruby/RubyKernel.java:982
      (root) at jruby-devel/lib/ruby/gems/shared/gems/bundler-1.1.3/lib/bundler/runtime.rb:1
      each at org/jruby/RubyArray.java:1611
      require at jruby-devel/lib/ruby/gems/shared/gems/bundler-1.1.3/lib/bundler/runtime.rb:68
      each at org/jruby/RubyArray.java:1611
      require at jruby-devel/lib/ruby/gems/shared/gems/bundler-1.1.3/lib/bundler/runtime.rb:66
      require at jruby-devel/lib/ruby/gems/shared/gems/bundler-1.1.3/lib/bundler/runtime.rb:55
      require at jruby-devel/lib/ruby/gems/shared/gems/bundler-1.1.3/lib/bundler.rb:119
      require at org/jruby/RubyKernel.java:982
      (root) at /path/to/project/config/application.rb:46
      require at org/jruby/RubyKernel.java:982
      (root) at vendor/bundle/jruby/1.8/gems/railties-3.2.3/lib/rails/commands/runner.rb:1
      require at org/jruby/RubyKernel.java:982
      (root) at script/rails:6

      vendor/bundle/jruby/1.8/gems/meta_search-1.1.3/lib/meta_search.rb
      50 require 'meta_search/searches/active_record'
      51 require 'meta_search/helpers'
      52
      53 I18n.load_path += Dir[File.join(File.dirname(__FILE__), 'meta_search', 'locale', '*.yml')]
      54
      55 ActiveRecord::Base.send(:include, MetaSearch::Searches::ActiveRecord)
      56 ActionView::Helpers::FormBuilder.send(:include, MetaSearch::Helpers::FormBuilder)
      57 ActionController::Base.helper(MetaSearch::Helpers::UrlHelper)
      58 ActionController::Base.helper(MetaSearch::Helpers::FormHelper)

      /path/to/project/config/application.rb
      44 if defined?(Bundler)
      45 # If you precompile assets before deploying to production, use this line
      46 Bundler.require(*Rails.groups(:assets => %w(development test)))
      47 # If you want your assets lazily compiled in production, use this line
      48 # Bundler.require(:default, :assets, Rails.env)
      49 end

        Activity

        Hide
        Subbu Sastry added a comment -

        Thanks for nailing the bug. Would you be able to reduce your example to a smaller test case?

        Show
        Subbu Sastry added a comment - Thanks for nailing the bug. Would you be able to reduce your example to a smaller test case?
        Hide
        Reto Schüttel added a comment -

        It only happens if I enable threadsafe! and set cache_class=true in development mode - which I do because work with threads for background jobs.

        I'll upload a minimal rails project. When you disable thread safety OR if you remove the dependency to devise the error goes away.

        Reto

        Show
        Reto Schüttel added a comment - It only happens if I enable threadsafe! and set cache_class=true in development mode - which I do because work with threads for background jobs. I'll upload a minimal rails project. When you disable thread safety OR if you remove the dependency to devise the error goes away. Reto
        Hide
        Reto Schüttel added a comment -

        unpack, jruby --1.8 -S bundle install and then jruby -S script/rails runner true

        Show
        Reto Schüttel added a comment - unpack, jruby --1.8 -S bundle install and then jruby -S script/rails runner true
        Hide
        Subbu Sastry added a comment -

        Thanks. will take a look

        Show
        Subbu Sastry added a comment - Thanks. will take a look
        Hide
        Subbu Sastry added a comment - - edited

        The code that triggers this bug is the code on line 17 in orm_adapter-0.0.7/lib/orm_adapter.rb (pasted below):

        require 'orm_adapter/adapters/active_record' if defined?(ActiveRecord::Base)

        Specifically, it is the defined? check that is triggering the bug.

        Enclosed below is a reduced code case that illustrates the bug more clearly. Please see embedded comment below that explains what is going on with this bug. I'll take up this discussion on the mailing list.

        Thanks Reto.

        ---------------------------------------------------

        class Object
        def self.const_missing(*args)
        puts "in const_missing! #

        {args.inspect}

        "
        raise "this_will_get_lost!"
        rescue Exception => e
        puts "Got exception: #

        {e}"
        end
        end

        begin
        raise "will_not_get_lost_1"
        rescue Exception => e
        puts "Got exception: #{e}

        "
        end

        # The bug is caused by the check on line 239 of org.jruby.exceptions.RaiseException.java
        # defined? sets the 'isWithinDefined' flag which basically suppresses setting of "$!" in
        # all code that runs downstream of defined?.
        #
        # In commit 20632af6e1fa511fd9b762beda2a60d39bf3c859, I got rid of a hack that was
        # setting "$!" to the received exception since I fixed the threading scenario where
        # $! was not being properly set. But, it now appears that the hack was also used to
        # get around the 'isWithinDefined' flag suppressing the setting of "$!" in defined?
        # downstream code.
        #
        # So, the question is if the check in RaiseException is required? Why is it there?
        defined?(Foo::Bar)

        begin
        raise "will_not_get_lost_2"
        rescue Exception => e
        puts "Got exception: #

        {e}

        "
        end

        Show
        Subbu Sastry added a comment - - edited The code that triggers this bug is the code on line 17 in orm_adapter-0.0.7/lib/orm_adapter.rb (pasted below): — require 'orm_adapter/adapters/active_record' if defined?(ActiveRecord::Base) — Specifically, it is the defined? check that is triggering the bug. Enclosed below is a reduced code case that illustrates the bug more clearly. Please see embedded comment below that explains what is going on with this bug. I'll take up this discussion on the mailing list. Thanks Reto. --------------------------------------------------- class Object def self.const_missing(*args) puts "in const_missing! # {args.inspect} " raise "this_will_get_lost!" rescue Exception => e puts "Got exception: # {e}" end end begin raise "will_not_get_lost_1" rescue Exception => e puts "Got exception: #{e} " end # The bug is caused by the check on line 239 of org.jruby.exceptions.RaiseException.java # defined? sets the 'isWithinDefined' flag which basically suppresses setting of "$!" in # all code that runs downstream of defined?. # # In commit 20632af6e1fa511fd9b762beda2a60d39bf3c859, I got rid of a hack that was # setting "$!" to the received exception since I fixed the threading scenario where # $! was not being properly set. But, it now appears that the hack was also used to # get around the 'isWithinDefined' flag suppressing the setting of "$!" in defined? # downstream code. # # So, the question is if the check in RaiseException is required? Why is it there? defined?(Foo::Bar) begin raise "will_not_get_lost_2" rescue Exception => e puts "Got exception: # {e} " end
        Hide
        Subbu Sastry added a comment -

        This is now fixed in commit 7c3f6426eb26e560f21b2f1905923fa624c4408c

        Show
        Subbu Sastry added a comment - This is now fixed in commit 7c3f6426eb26e560f21b2f1905923fa624c4408c
        Hide
        Thomas E Enebo added a comment -

        Fixed by subbu...less cruft, more tufft (subbu I could not assign this to you...hmm)

        Show
        Thomas E Enebo added a comment - Fixed by subbu...less cruft, more tufft (subbu I could not assign this to you...hmm)

          People

          • Assignee:
            Thomas E Enebo
            Reporter:
            Reto Schüttel
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: