Hi Charles,

> lines long, but still. A more durable hack would be to have a hook in the
> > findFileInClasspath method that calls a URL rewriter method, which has a
> > default implementation in the JRuby code that simply returns the URL.
> Then
> > we would only have to overwrite that method, instead of the whole 50
> lines.
>
> Well, that's a pretty good idea. We could certainly structure it that
> way. LoadService needs more refactoring/cleanup in general, and
> ideally I have always wanted it to either work more like classloading
> does (cascading hierarchy of searches) or to allow simple registration
> of lookup logic. That would allow you to add your own
> classloader-based searches using specialized URL logic.


We've settled on a very simple solution that involves very little code
change to JRuby, with one new protected method in LoadService that simply
takes a URL and returns it. This method can be overridden in special
environments, like equinox, to instead re-write the URL from equinox
specific to more general (from using protocol 'bundleentry' to protocol
'file' or 'jar').

I'm really open to any suggestion here. Along with handling these
> custom URLs, we would also like to be able to handle
> resources-within-resources, which requires similar custom URL
> handling. So a general approach is certainly needed.


Well, the current code will re-write 'bundleentry' to 'file' or 'jar', but
we've not actually tested if the rest of the LoadService will handle 'jar'.
I assumed it would. I can see support for loadingf scripts in jars, but have
not traced all the code to be sure our fix actually enables that code. It
certainly works in our un-jarred development environment, but in a deployed
environment we might need to make a few further modifications.

If you want to mock up an idea or patch and stick it into a JIRA
> "feature" bug, we could go from there and try to get it into JRuby
> proper.


I think our current code is good enough to post to a JIRA 'feature' bug.
Shall I go ahead and do that or would you prefer we've confirmed that it
works in a jarred up deployment environment first?

Cheers, Craig

Reply via email to