Re: Relieving some ClassLoader contention in PreferredClassProvider

On Fri, Jan 05, 2007 at 12:24:56PM -0600, Gregg Wonderly wrote:
>
> Peter Jones wrote:
>
>> I'm confused: if it returns a "deferred http: URL openConnection()
>> value", I still wouldn't expect an HTTP request to be attempted
>> here?
>
> Most of the time it's returning a file: URL connection to cached
> data.  Thus, when its openConnection() is called, it has made the
> http (or whatever protocol is deferred to) connection, downloaded
> the data, and then returns the results of openConnection() on the
> file: URL pointing at that data.

Ah, I see.  Well, that breaks PreferredClassLoader's expectation that
just invoking URL.openConnection will not actually make a connection
to the target-- and I think that that expectation is reasonable.  I
wonder if you could restructure the handler implementation so that it
returns a custom URLConnection subclass that defers the activities you
describe above (both loading from the HTTP URL and from the file
cache) until methods like connect or getInputStream are invoked on it.
This structure would also provide more control over the getPermission
behabior (see below).

>> And separate from the primary topic of this discussion: I don't
>> recall exactly what your vhttp handler does, but I wonder if the
>> right permission is getting returned.  If an HTTP URL is always the
>> original source from which the data will have been obtained, then
>> permission to connect to it would seem to be what should count,
>> regardless of whether data cached in the file system will be used.
>
> It's a caching handler that also includes a download listener
> interface that allows software using it, to see that downloads have
> started and display progress of those downloads if needed.
>
> The resulting permissions are an interesting question.  That's not
> an issue that I've considered to this point.  With my permission
> model, I've always get access failures in storing cached data
> because the codebase does not have access to the filesystem to write
> the data.
>
> We can discuss the permission issue further, if you want...

Given my current understanding of your caching HTTP URL handler, I
think that it should always be returning the permission that a
corresponding HTTP URLConnection would return, regardless of the
caching behavior.  More specifically, before one of the handler's
URLConnections is "connected", its getPermission should return the
permission from any corresponding "unconnected" HTTP URLConnection;
after being "connnected", getPermission should return the permission
from the corresponding "connected" HTTP URLConnection that was used to
retrieve the data-- suggesting that the permission would need to be
stored in the cache along with the data.  And the handler
implementation, which is presumably fully trusted (by being
installed), would then read and write from the file cache in a
doPrivileged block, and during a "connection" attempt that used cached
data instead of making an HTTP connection, it would explicitly check
the permission stored in the cache.

(This distinction about checking a possibly different permission in
the connected case is concerned about HTTP redirects causing a
connection to a different host/port than is in the original URL, which
can't be known until the data corresponding to the permission check is
retrieved-- for more about this, see the URLConnection.getPermission
doc.  If you know that this URL handler will only ever be used for RMI
codebase URLs, then you might be able to get away with ignoring this
distinction, because RMIClassLoader providers essentially have to
disallow HTTP redirects for security permission reasons anyway: that's
largely the point of why PreferredClassProvider creates
PreferredClassLoaders in such a restricted access control context-- to
be sure that the loader isn't exercising network permissions than were
checked by the original RMIClassLoader.loadClass invocation.)

-- Peter

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]