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

Setting load path on ScriptingContainer with LocalContextScope.SINGLETON does not work

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: JRuby 1.6.5, JRuby 1.7.0.pre1
    • Fix Version/s: JRuby 1.7.0.pre1
    • Component/s: Embedding
    • Labels:
      None
    • Environment:
      OS X 10.7.2
      jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java]
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      See the following jirb session:

      macbeth:ruboto-core uwe$ jirb
      >> require 'java'
      => true
      >> s = org.jruby.embed.ScriptingContainer.new(org.jruby.embed.LocalContextScope::SINGLETON)
      => #<Java::OrgJrubyEmbed::ScriptingContainer:0x4280bc28>
      >> s.load_paths.add '/tmp'
      => true
      >> s.runScriptlet 'p $:'
      ["/Library/Frameworks/JRuby.framework/Gems/1.8/gems/wirble-0.1.3/lib", "/Library/Frameworks/JRuby.framework/Versions/1.6.5/lib/ruby/site_ruby/1.8", "/Library/Frameworks/JRuby.framework/Versions/1.6.5/lib/ruby/site_ruby/shared", "/Library/Frameworks/JRuby.framework/Versions/1.6.5/lib/ruby/1.8", "."]
      => nil
      

      However when using LocalContextScope.SINGLETHREAD the path is added:

      macbeth:ruboto-core uwe$ jirb
      >> require 'java'
      => true
      >> s = org.jruby.embed.ScriptingContainer.new(org.jruby.embed.LocalContextScope::SINGLETHREAD)
      => #<Java::OrgJrubyEmbed::ScriptingContainer:0x441743be>
      >> s.load_paths.add '/tmp'
      => true
      >> s.runScriptlet 'p $:'
      ["/tmp", "/Library/Frameworks/JRuby.framework/Versions/1.6.5/lib/ruby/site_ruby/1.8", "/Library/Frameworks/JRuby.framework/Versions/1.6.5/lib/ruby/site_ruby/shared", "/Library/Frameworks/JRuby.framework/Versions/1.6.5/lib/ruby/1.8", "."]
      => nil
      

      Shouldn't the extra load path be added for SINGLETON as well?

        Activity

        Hide
        Yoko Harada added a comment -

        I see the problem. I'll look in to it.

        Let me add the reason of this bug. In this case, jirb creates Ruby runtime and ScriptingContainer uses that runtime. So, if you set a load_path not on jirb (in a Java code), probably, this doesn't happen.

        Show
        Yoko Harada added a comment - I see the problem. I'll look in to it. Let me add the reason of this bug. In this case, jirb creates Ruby runtime and ScriptingContainer uses that runtime. So, if you set a load_path not on jirb (in a Java code), probably, this doesn't happen.
        Hide
        Yoko Harada added a comment -

        Perhaps, JRuby 1.6.6 will be out in some point. Do you want this in 1.6.6? or 1.7?

        Show
        Yoko Harada added a comment - Perhaps, JRuby 1.6.6 will be out in some point. Do you want this in 1.6.6? or 1.7?
        Hide
        Uwe Kubosch added a comment -

        Hi Yoko!

        My concrete use is with Ruboto, and in that case we only create one instance of ScriptingContainer, but still the load path is not added.

        We only need it for JRuby 1.7.

        I will try a Java example.

        Show
        Uwe Kubosch added a comment - Hi Yoko! My concrete use is with Ruboto, and in that case we only create one instance of ScriptingContainer, but still the load path is not added. We only need it for JRuby 1.7. I will try a Java example.
        Hide
        Uwe Kubosch added a comment -

        Just tried a Java example, and it seems to work as expected. I will look into why it doesn't work with Ruboto.

        Show
        Uwe Kubosch added a comment - Just tried a Java example, and it seems to work as expected. I will look into why it doesn't work with Ruboto.
        Hide
        Uwe Kubosch added a comment -

        Running the same test multiple times on Ruboto sometimes succeeds and sometimes failed...I have no idea why, yet.

        Show
        Uwe Kubosch added a comment - Running the same test multiple times on Ruboto sometimes succeeds and sometimes failed...I have no idea why, yet.
        Hide
        Uwe Kubosch added a comment -

        So, I have solved our problem by running a scriptlet that adds the desired path to $:

        This is an acceptable workaround for us, and I am not sure there is anything wrong with the ScriptingContainer. If I have the time, I will investigate this, but for now, I think we should close this issue.

        Show
        Uwe Kubosch added a comment - So, I have solved our problem by running a scriptlet that adds the desired path to $: This is an acceptable workaround for us, and I am not sure there is anything wrong with the ScriptingContainer. If I have the time, I will investigate this, but for now, I think we should close this issue.
        Hide
        Yoko Harada added a comment -

        That sounds weird. Does Android cache instances?

        Probably, a ruby way would work in any case. If you evaluate "$: << '/tmp'" on ScriptingContainer, it does what you want, I think.

        If you feel OK to close this issue, please do so.

        Show
        Yoko Harada added a comment - That sounds weird. Does Android cache instances? Probably, a ruby way would work in any case. If you evaluate "$: << '/tmp'" on ScriptingContainer, it does what you want, I think. If you feel OK to close this issue, please do so.
        Hide
        Uwe Kubosch added a comment -

        Closing since there is a workaround and reproducing is not a priority for now.

        Show
        Uwe Kubosch added a comment - Closing since there is a workaround and reproducing is not a priority for now.

          People

          • Assignee:
            Yoko Harada
            Reporter:
            Uwe Kubosch
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: