Exported resources

[Glyn Normington]

Some feedback from an observer which may help:

> Bryan misses the need for extender model to load internal impl classes
ala
> Bundle.loadClass in OSGi.
>
> You do not want to have to export the service impl class from a module.
> You want to hide the class from others' casual loading. However an
> extender bundle (e.g. ServiceLoader) will need to be able to load that
> class to make it instances of it available to others under the service
> interface class.

Glyn

Bryan Atsatt <bryan.atsatt at ORACLE.COM> wrote on 30/05/2007 21:21:36:

> I've been assuming that Module private resources should not be visible
> to *any* class outside of the module. Including ResourceBundle, or any
> other existing framework classes that do resource lookups (e.g.
> ServiceLoader, JSF, etc). If resources need to be visible to these
> existing classes, they must be exported. The very simple check I
> proposed (immediate caller) is sufficient to make this assertion.
>
> I believe your point is that if we used the permission model instead, it
> would become possible for a module to invoke an external class (e.g.
> ResourceBundle.getBundle()) and enable *it* to successfully load a
> private resource from the module.
>
> Aside from the permission *grant* mechanism this model would rely on, it
> is an entirely different model than that used for classes! (Though we
> haven't explicitly defined this in 294, it seems extremely unlikely that
> we will rely on permissions--none of the other access modes do so.) Such
> asymmetry is very disconcerting to me, and, I believe, just plain
wrong...
>
> Consider that you could grant the ServiceLoader, for example, access to
> a resource that names a class that it could not instantiate. That class
> would have to be exported. I believe the resource should be as well.
>
> // Bryan
>
>
>
>
> Stanley M. Ho wrote:
> > Hi Bryan,
> >
> > Those resource-related methods in ClassLoader can be called by anyone,
> > including code that is part of the module, code that is from other
> > modules, or code that is part of the platform libraries (e.g.
> > ResourceBundle). The approach you described would require walking the
> > stack to get the caller's Module, but the real issue is that it is
> > difficult to determine who the actual caller is from the stack.
> >
> > Treating the immediate caller on the stack as the actual caller
wouldn't
> > be sufficient because the immediate caller could be called by someone
> > else who is the one actually making the call. On the other hand,
> > treating the originated caller on the stack as the actual caller would
> > be the right semantic, but this is basically the same as the security
> > permission approach.
> >
> > - Stanley
> >
> >
> > Bryan Atsatt wrote:
> >> Both solutions require stack walking (unless there is some new
> >> implementation of the java security model I've not yet seen!).
> >>
> >> The permission check does much more work than is necessary here. Take
a
> >> look at AccessController.checkPermission() to see what I mean.
> >>
> >> And actually there is a very simple API to get the stack, which I've
> >> used for years:
> >>
> >>   private static class StackAccessor extends SecurityManager {
> >>       public Class[] getStack() {
> >>           return getClassContext();
> >>       }
> >>   }
> >>
> >>   private static final STACK_ACCESSOR = new StackAccessor();
> >>
> >> Now the enclosing class can simply call STACK_ACCESSOR.getStack().
> >>
> >> // Bryan
> >>
> >>
> >>
> >> Stanley M. Ho wrote:
> >>> Hi Bryan,
> >>>
> >>> Bryan Atsatt wrote:
> >>>> 1. Definitely agree that resource search order should be identical
to
> >>>> class search order.
> >>>
> >>> Glad to hear!
> >>>
> >>>> 2. Using permissions to limit access to private resources seems
like
> >>>> overkill to me. The prototype implemented this in a very simple
> >>>> fashion:
> >>>>
> >>>> a. If resource is exported, return it, else
> >>>> a. Get the caller's Module (get class from stack, get module from
it)
> >>>> b. If callerModule == this, return resource, else return null.
> >>>
> >>> The issue is that this approach still requires stack walking and
there
> >>> is no public API in the SE platform that let you implement this.
> >>>
> >>> If stack walking is required for the check anyway, I think the
security
> >>> permission approach is better that it is implementable with the
existing
> >>> API in the SE platform.
> >>>
> >>> - Stanley
> >>>
> >






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070531/0f8f8542/attachment.html