JRuby

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: