[jira] Commented: (RIVER-314) Enhanced codebase download

["Peter Jones (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RIVER-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743814#action_12743814 ] 

Peter Jones commented on RIVER-314:
-----------------------------------

Methods for overriding whether a class is preferred would not seem to belong in net.jini.loader.ClassLoading-- ClassLoading is a wrapper around the static methods of java.rmi.server.RMIClassLoader to add support for codebase integrity verification, but it is meant to be independent of the particular RMIClassLoader provider in use, and thus independent of the "preferred" semantics of net.jini.pref.PreferredClassProvider.  (As is, the submitted code doesn't quite implement non-preferred semantics of PreferredClassProvider anyway, because it only tries the default loader and ClassLoading's own loader, but never the current thread's context class loader.)

Such functionality would belong somewhere in the net.jini.loader.pref package, with appropriate security checks.  It could be applied to whole directories and namespaces like wildcard preferred list entries, and it could be applied to resource loading as well as class loading.  The general idea would be to short circuit PreferredClassLoader.isPreferredResource before it would otherwise force downloading of the first element of the codebase URL path in order to get the preferred list.

Note that there is no need to specify the preferred setting of an array class-- its preferred setting is always the same as that of its element type (which is of course always false for primitive types).

Certainly any class whose binary name begins with "java." cannot be successfully preferred, so it would seem reasonable to short circuit that namespace by default (I thought that we were doing that at some point...).


> Enhanced codebase download
> --------------------------
>
>                 Key: RIVER-314
>                 URL: https://issues.apache.org/jira/browse/RIVER-314
>             Project: River
>          Issue Type: New Feature
>            Reporter: Tom Hobbs
>         Attachments: ClassLoading.java
>
>
> Direct copy from the mailing list:
> "I'm also thinking that if we add support of compression to the http codebase (and serialization), we can download individual class files over the network individually instead of entire jar files (repeatedly compressed class files would be cached, to reduce CPU overhead).  This might make performance a bit snappier when only requiring a few classes from a large library that would normally be stored in a jar for instance."
> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200907.mbox/%3c4A5C8272.5070403@zeus.net.au%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.