We’re running our script inside a ScriptingContainer with a custom
classloader that helps us find scripts in particular places. When trying
to
File.read a file with a name like “classpath:/path/to/file” we expected
that
classpath request to end up in the same classloader but, nay, it didn’t.
The
stacktrace revealed the problem; to wit, the resource is being loaded
using ByteList.EMPTY_BYTELIST.getClass().getClassLoader(). QQ This seems
inconsistent. Is there a reason for not at least attempting to use the
classloader set on the scripting container? Here’s the line
(ChannelDescriptor.java:660)
Ah, so ChannelDescriptor.open method seems to need one more argument
for classloader. As far as I looked at related codes, the fix should
be easy. Would you file this to JIRA?
ScriptingContainer is new API for JRuby, and JRuby on custom
classloader is also new style. So, as you wrote, JRuby would have some
inconsistent implementations which has not yet revealed.
I had actually already put together a hacked jruby doing just what you
suggested but wasn’t sure if it was good idea - I’m glad I wasn’t too far
off base. I’ll put it up in JIRA with the patch when I have a moment - is
there a preferred format for the patch?
Git friendly patch would be nice since JRuby uses git.
I had actually already put together a hacked jruby doing just what you
suggested but wasn’t sure if it was good idea - I’m glad I wasn’t too
far
off base. I’ll put it up in JIRA with the patch when I have a moment -
is
there a preferred format for the patch?
Thanks!
Najati
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.