Thanks Nick,

Your explanation certainly derails my previous 'theory' :-(

We're working with pathnames here, not contents, so we don't actually go so
> far as to open the URL or get its contents, so I'm not sure that what you're
> describing will actually work. I'd consider it an enhancement at this point
> to make something like "IO.readlines('bundleresource://9/./some_script.rb')"
> actually do what you expect (though note that this isn't the same problem
> that the OP mentioned).
>

I guess IO.readlines() expects a filepath, not a url spec. I wonder if a
hack like providing an alternative implementation of IO.readlines() that
will consider the parameter as a url spec will work? That should have no
change to JRuby code, and only requires that we take the (dangerous?)
approach of adding an alternative IO impl in our deployment. (dangerous =
risk of breaking the conformance to the RubySpec)

Context classloader bugs in JRuby were fixed long ago, so I'm less suspect
> of that being the problem.
>

I'm sure you are right. However that does not rule out bugs in our plugins
that create the JRuby. I think we still have to get our ducks in a row to
make this work properly. I remember that last time I wrote JRuby startup
code, I needed to set the context classloader in the current thread before
starting the ruby runtime, otherwise none of the dependent plugins were
visible to JRuby, so it seems there is stuff the developer needs to think
about for this all to work.

Is there perhaps a wiki page or decent discussion on the JRuby Context
classloader setup? I worked out the thread trick last year by reading JRuby
code, but that does not mean I actually understood the details of what was
going on. I think this is a tricky area and a decent writeup would be great.

I'm actually quite happy to do that writeup myself, if I can get some
pointers to the right information, even if that is just the relevant bits of
code in JRuby to look through.

Cheers, Craig

Reply via email to