river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Trasuk (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RIVER-149) net.jini.export.ServerContext spec shouldn't rely on the system classloader
Date Thu, 24 Nov 2011 14:59:39 GMT

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

Greg Trasuk commented on RIVER-149:

This bug prevents proper hosting of services inside a container.  

I propose making the providers load from the current thread's context class loader, as described
in Peter Jones' comment above.

> 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
> 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


View raw message