<br><tt><font size=2>Some feedback from an observer which may help:</font></tt>
<br>
<br><tt><font size=2>> Bryan misses the need for extender model to load
internal impl classes ala <br>
> Bundle.loadClass in OSGi.<br>
> <br>
> You do not want to have to export the service impl class from a module.
<br>
> You want to hide the class from others' casual loading. However an
<br>
> extender bundle (e.g. ServiceLoader) will need to be able to load
that <br>
> class to make it instances of it available to others under the service
<br>
> interface class.</font></tt>
<br><font size=2 face="sans-serif"><br>
Glyn</font>
<br>
<br><font size=1 face="sans-serif"><b>Bryan Atsatt <bryan.atsatt@ORACLE.COM></b></font><tt><font size=2>
wrote on 30/05/2007 21:21:36:<br>
<br>
> I've been assuming that Module private resources should not be visible<br>
> to *any* class outside of the module. Including ResourceBundle, or
any<br>
> other existing framework classes that do resource lookups (e.g.<br>
> ServiceLoader, JSF, etc). If resources need to be visible to these<br>
> existing classes, they must be exported. The very simple check I<br>
> proposed (immediate caller) is sufficient to make this assertion.<br>
> <br>
> I believe your point is that if we used the permission model instead,
it<br>
> would become possible for a module to invoke an external class (e.g.<br>
> ResourceBundle.getBundle()) and enable *it* to successfully load a<br>
> private resource from the module.<br>
> <br>
> Aside from the permission *grant* mechanism this model would rely
on, it<br>
> is an entirely different model than that used for classes! (Though
we<br>
> haven't explicitly defined this in 294, it seems extremely unlikely
that<br>
> we will rely on permissions--none of the other access modes do so.)
Such<br>
> asymmetry is very disconcerting to me, and, I believe, just plain
wrong...<br>
> <br>
> Consider that you could grant the ServiceLoader, for example, access
to<br>
> a resource that names a class that it could not instantiate. That
class<br>
> would have to be exported. I believe the resource should be as well.<br>
> <br>
> // Bryan<br>
> <br>
> <br>
> <br>
> <br>
> Stanley M. Ho wrote:<br>
> > Hi Bryan,<br>
> ><br>
> > Those resource-related methods in ClassLoader can be called by
anyone,<br>
> > including code that is part of the module, code that is from
other<br>
> > modules, or code that is part of the platform libraries (e.g.<br>
> > ResourceBundle). The approach you described would require walking
the<br>
> > stack to get the caller's Module, but the real issue is that
it is<br>
> > difficult to determine who the actual caller is from the stack.<br>
> ><br>
> > Treating the immediate caller on the stack as the actual caller
wouldn't<br>
> > be sufficient because the immediate caller could be called by
someone<br>
> > else who is the one actually making the call. On the other hand,<br>
> > treating the originated caller on the stack as the actual caller
would<br>
> > be the right semantic, but this is basically the same as the
security<br>
> > permission approach.<br>
> ><br>
> > - Stanley<br>
> ><br>
> ><br>
> > Bryan Atsatt wrote:<br>
> >> Both solutions require stack walking (unless there is some
new<br>
> >> implementation of the java security model I've not yet seen!).<br>
> >><br>
> >> The permission check does much more work than is necessary
here. Take a<br>
> >> look at AccessController.checkPermission() to see what I
mean.<br>
> >><br>
> >> And actually there is a very simple API to get the stack,
which I've<br>
> >> used for years:<br>
> >><br>
> >> private static class StackAccessor extends SecurityManager
{<br>
> >> public Class[] getStack() {<br>
> >> return getClassContext();<br>
> >> }<br>
> >> }<br>
> >><br>
> >> private static final STACK_ACCESSOR = new StackAccessor();<br>
> >><br>
> >> Now the enclosing class can simply call STACK_ACCESSOR.getStack().<br>
> >><br>
> >> // Bryan<br>
> >><br>
> >><br>
> >><br>
> >> Stanley M. Ho wrote:<br>
> >>> Hi Bryan,<br>
> >>><br>
> >>> Bryan Atsatt wrote:<br>
> >>>> 1. Definitely agree that resource search order should
be identical to<br>
> >>>> class search order.<br>
> >>><br>
> >>> Glad to hear!<br>
> >>><br>
> >>>> 2. Using permissions to limit access to private resources
seems like<br>
> >>>> overkill to me. The prototype implemented this in
a very simple<br>
> >>>> fashion:<br>
> >>>><br>
> >>>> a. If resource is exported, return it, else<br>
> >>>> a. Get the caller's Module (get class from stack,
get module from it)<br>
> >>>> b. If callerModule == this, return resource, else
return null.<br>
> >>><br>
> >>> The issue is that this approach still requires stack
walking and there<br>
> >>> is no public API in the SE platform that let you implement
this.<br>
> >>><br>
> >>> If stack walking is required for the check anyway, I
think the security<br>
> >>> permission approach is better that it is implementable
with the existing<br>
> >>> API in the SE platform.<br>
> >>><br>
> >>> - Stanley<br>
> >>><br>
> ><br>
</font></tt><font size=3 face="sans-serif"><br>
</font>
<br><font size=3 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3 face="sans-serif"><br>
</font>
<br>
<br><font size=3 face="sans-serif"><br>
</font>