Refactor LoadService for consistency, pluggability (and performance?)
---------------------------------------------------------------------
Key: JRUBY-4163
URL: http://jira.codehaus.org/browse/JRUBY-4163
Project: JRuby
Issue Type: Bug
Components: Miscellaneous
Affects Versions: JRuby 1.4
Reporter: Charles Oliver Nutter
Fix For: JRuby 1.5
Some effort has been made to simplify and break apart LoadService, but that
work was never really completed.
>From Bob McWhirter's comment on JRUBY-4138:
I'd see a refactoring go something like this:
1) Turn LoadService into simple interface (require(...) and load(...) only).
2) Create a DefaultLoadService (or whatever naming you like) which assembles
LoadStrategy instances, plus a default assemblage of them.
3) Break each strategy into its own self-contained (and inheritable) class,
instead of calling back to LoadStrategy.findWithoutCWD() and others. This
would help with composition.
4) For any strategy dealing with streams/files/resources/directories/paths, I'd
like to see the finding aspect of it broken into an overridable method. If
this were the case, it'd be easy for me to add support for vfszip:// URLs
without have to copy/paste/redo the entire load-path search strategy.
Something akin to
{code}
public InputStream find(String loadPathEntry, String path) {
if ( loadPathEntry.startsWith( "vfszip://" ) ) {
return findViaVFS( loadPathEntry, path );
} else {
return super.find( loadPathEntry, path );
}
}
{code}
As it currently (1.3.1) stands, I had to deal with manipulating the
loadedFeatures bits and such myself, in order to also be able to just load
streams from vfszip. Separating out the find-the-resource behaviour from the
what-do-we-do-with-a-found-resource behaviour would be excellent.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
