[
https://issues.apache.org/jira/browse/RIVER-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165321#comment-13165321
]
Hudson commented on RIVER-149:
------------------------------
Integrated in River-trunk #497 (See
[https://builds.apache.org/job/River-trunk/497/])
Fix RIVER-149.
gtrasuk : http://svn.apache.org/viewvc/?view=rev&rev=1211940
Files :
* /river/jtsk/trunk
* /river/jtsk/trunk/src/com/sun/jini/resource/Service.java
* /river/jtsk/trunk/src/net/jini/config/ConfigurationProvider.java
* /river/jtsk/trunk/src/net/jini/export/ServerContext.java
> 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
> 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.
> [email protected] 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.
> [email protected] 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.
> [email protected] 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
