You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Greg Trasuk (Resolved) (JIRA)" <ji...@apache.org> on 2011/12/08 21:34:40 UTC
[jira] [Resolved] (RIVER-149) net.jini.export.ServerContext spec
shouldn't rely on the system classloader
[ https://issues.apache.org/jira/browse/RIVER-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Trasuk resolved RIVER-149.
-------------------------------
Resolution: Fixed
Fix Version/s: AR4
Assignee: Greg Trasuk
Modified to use the current thread's context classloader, and to only look for context provider if necessary. Since use of JRMP is deprecated in favour of JERI, lookups for context provider should be rare (JERI provides its context explicitly through its own invocation layer).
> net.jini.export.ServerContext spec shouldn't rely on the system classloader
> ---------------------------------------------------------------------------
>
> Key: RIVER-149
> URL: https://issues.apache.org/jira/browse/RIVER-149
> Project: River
> Issue Type: Bug
> Components: net_jini_export
> Affects Versions: jtsk_2.0_001
> Reporter: Bob Scheifler
> Assignee: Greg Trasuk
> Fix For: AR4
>
> Attachments: River-149-patch.diff
>
>
> Bugtraq ID [6190263|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6190263]
> The specification of net.jini.export.ServerContext.getServerContext() describes a process in which classes are loaded by the system classloader and a determination is made about assignability to the ServiceContext.Spi interface. This requires that this interface must also have been loaded by the system classloader.
> It is reasonable that an application may, directly or indirectly, start Jini components in one or more separate classloaders (for which it is not the parent). In this case, the ServiceContext.Spi interface and the classes loaded by the system classloader will be from different classloaders (and different contexts).
> The specification and implementation should change. I suggest that the classloader which loaded the ServiceContext should be the loader which loads the specified classes.
> fred.oliver@sun.com 11/3/04 20:37 GMT
> Evaluation
> net.jini.export.ServerContext is indeed currently specified with the assumption that it is loadable by the system class loader.
> Loading the provider resources and classes from ServerContext's defining loader would not support the case of ServerContext being installed as an extension but application provider classes only available in the class path-- which works currently and is a typical case.
> Loading provider resources and classes for a VM-global provider setting from the system class loader is typical in J2SE-- examples include the handler for a given URL scheme, the NIO SelectorProvider, and the RMIClassLoader provider. Using the system class loader for these VM-global provider settings is a compromise to support application provider classes (i.e. they can be found in the class path) without allowing the setting to be wrongly biased by an arbitrary application context (such as if the current thread's context class loader were used, when initializing the setting on first use). [Of course, J2SE-defined provider lookup mechanisms are generally free from worry about the issue of this bug, because the provider type is presumably always defined by the bootstrap class loader.]
> A reasonable question might be, however, does the list of provider's consulted by ServerContext.getServerContext really need to be VM-global? Why couldn't its behavior (when there is no explicit doWithServerContext in effect) be a function of the current thread's context class loader? (For performance, results of the provider lookup could be weakly cached per context class loader.) Even if such a change were to seem functionally correct, the security implications would of course need to be carefully considered too. ServerContext.Spi is an interface, so a constructor permission requirement cannot be added (like was added to java.nio.channels.SelectorProvider). Various security-related Jini APIs do already imply a reasonable amount of trust in classes loadable by the current thread's context class loader.
> Another consideration for this bug is how important do we think it is to support deployments in which ServerContext is defined by a class loader that is not an ancestor or descendant of the system class loader.
> peter.jones@sun.com 11/4/04 00:24 GMT
> Entry 1 peter.jones [2004-11-04 00:24]
> Comments
> The call stack for an instance of the ill-defined behavior.
> Service.fail:149
> Service.access$000:140
> ServerContext$1.run:72
> AccessCOntroller.doPrivileged
> Security$4.run:519
> AccessController.doPrivileged
> Security.doPrivileged:517
> ServerContext.<clinit>:65
> ObjectTable$Target.dispatch0:606
> ObjectTable$Target.access$700:227
> ObjectTable$5.run
> AggregatePolicyProvider$6.run:554
> AccessController.doPriveleged
> ObjectTable$Target.dispatch:578
> ObjectTable$Target.dispatch:555
> ObjectTable$RD.dispatch 789
> ServerConnectionManager$DispatchManager:163
> MuxServer$2.run:252
> AggregatePolicyProvider$5.run:540
> AccessController.doPrivileged
> MuxServer$1.run:249
> ThreadPool$Worker.run:151
> Thread.run:534
> In this case, a Main program is started and run with start.jar in its classpath. The Main program creates a new classloader (whose parent is the extension classloader) in which to run Jini components, in order to isolate them.
> fred.oliver@sun.com 11/3/04 19:30 GMT
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira